Version 0107

Updated by Leigh Hutchens

Release date May 5, 2021

In April 2021, we officially dropped support for Microsoft Internet Explorer 11 in favor of its successor Microsoft Edge. This means that we will no longer guarantee that Quinyx works in Internet Explorer 11, and we will no longer perform any pre-release testing of Quinyx in Internet Explorer.

Update for browser issue with editing shift/punch/absence times

A few weeks ago, an issue arose due to a bug in Chromium, the browser engine used by popular browsers such as Google Chrome and Microsoft Edge. This caused time input in Quinyx to not highlight when clicking on them. This was most obvious when trying to edit the start or end times on shifts, punches, and absences. The issue has now been resolved by the chromium project. Updating the browser ensures this fix is applied to the browser, and the hours will then highlight again.

New functionality

Overtime methods

With this release, we're adding initial support for Overtime methods management. You're now able to view the list of available overtime methods and search by name. 

List of Overtime methods

You’ll find a section called “Overtime methods” under the agreements header in account settings. When you navigate to that section, you’ll see a list of all available Overtime methods:

With this release, it's only possible to view the list. In coming releases, we'll add support for adding and editing Overtime methods.

Updates and performance improvements

Improved count logic for employee metrics in Schedule

Up until this release, the employee metrics in Schedule counted and displayed data from Time-daybreak to Time-daybreak for any given employee. By Time-daybreak, we’re referring to the value in the Daybreak field in Agreement > Advanced setting categories > Time > Rules for time punching > Daybreak. In the below example, user Gregory Payne has Time-daybreak 01:00, and as you can see, only the hours prior to 01:00 in the selected period of Monday May 3 are counted in the employee metrics:

As you can see in the Time card, the issue is that if you were to transfer only this date to payroll, you would transfer 3.5 hours and not 0.5.

The reason for this logic in the Time card is that when transferring to payroll, Quinyx will transfer the hours of all shifts starting prior to the Time-daybreak of the transferred dates. The employee metrics are to help you keep track of hours, and ultimately, to mitigate additional time and/or overtime compensation - meaning this mismatch between the metrics and the time card / payroll outcome has been suboptimal when there are shifts crossing the Time-daybreak.

So, in order to better take into account the calculations performed by Quinyx when running payroll, the employee metrics in Schedule will, as of this release, instead count and display the hours of all shifts starting prior to the Time-daybreak. This means we will, for the same user, Time-daybreak, date and shift, get this result:

We’ve explained the above changes using the employee metrics’ “selected period”, but the same change applies to “schedule period” and “balance period” in those same metrics. Any warnings about nominal hours, weekly hours, etc., now also take this new count logic into account.

The above only applies to Schedule - the same change is coming to Base schedule very soon.

Base schedule re-rollout warning

We've made a small improvement to the re-roll out warning in base schedule: 

  • As of this release, Quinyx will only show the re-roll out warning message (see image below) if there's an overlap of employees between current roll out and previous.
  • Example: If you roll out 15 employees the first time, and then one of those 15 employees is rolled out a second time the same or partly the same time period, the warning message is displayed:

Bug fixes

  • Resolved an issue that prevented a notice of interest from being deleted after assigning a shift until the page was refreshed.
  • Resolved an issue affecting shifts spanning midnight and caused a task to be deleted after midnight if an absence was added on part of the shift before midnight.
  • Resolved an issue that produced the error message “No active agreement” when adding a shift to one date and then moving it to a different date.
  • Resolved a statistics issue that caused the actual forecasted sales value to double.
  • Resolved an issue that prevented the Salary details report from correctly sorting in alphabetical order. 
  • Resolved an issue that prevented a 24 hour shift type from being added to the schedule.
  • Resolved a base schedule issue that didn’t count hours correctly when a shift was added to the last day of an employment period.
  • Resolved an issue that produced a warning that time exceeded scheduled time per day/week when rolling out a base schedule or adding a shift to the schedule directly.  
  • Resolved an issue where, when the "Generate salary on tasks" setting was enabled, scheduling warnings such as "Max scheduled hours per week exceeded", "Minimum daily rest requirement not met" and "Minimum weekly rest requirement not met" considered even shifts specifically set to not count as scheduled time.
  • Resolved an issue that produced a 500 error when connecting a previously added punch without a shift to a shift.
  • Resolved an issue where warnings generated by batch copying of shifts didn't clear on "Save".  
  • Resolved an issue that caused a punched break in the Time card to be longer than the actual punched break. 
  • Resolved an issue that produced a 403 error when two managers were editing the same shift at the same time and one deleted the shift before the other manager had saved.
  • Resolved an issue where the hour headings were duplicated in statistics in the base schedule day view.
  • Resolved an issue where any hours taking place on the Employed to-date of an employee quitting wouldn't count to the employee metrics by the employee avatar.
  • Resolved an issue with vacation hours not split correctly between statutory / non-statutory hours in case of new agreement in the future during same periodized year
  • Correction to wsdlMoveEmployee updating the active flag to 1 in some scenarios.
  • Correction to Shifts not counted as scheduled hours show as scheduled hours in the Analytics > Employee hours report.
  • Resolved an issue where calculated variable and edited forecast data would not display on dashboard widgets.

New HelpDocs articles

REST API / Web service updates

None at this time.

SOAP API / Web service updates

None at this time.

HTTPS information

At Quinyx, we've moved to HTTPS for all of our customers except a single endpoint for backwards compatibility. This endpoint is for WSDL integrations and only available on the address To ensure your customer data is safe and secure, this HTTP endpoint will be deprecated. The documented URL for Quinyx WSDL is:

This is why on 1st of May 2021 on the production environment, we'll disable port 80 and only allow 443 (HTTPS) on the following endpoints:

How does this affect you?

Endpoints being deprecated and removed

If you're still pointing to this endpoint on port 80, you have to change these integrations to port 443, i.e., HTTPS. You can already do this and test that everything works as expected.

The following SOAP API endpoints will be discontinued and removed from Quinyx WFM August 2021.They are already now replaced with REST API endpoints for Quinyx Forecast or obsolete. Read more about Quinyx Forecast and the improved functionality here and about the new REST APIs here.

6.2 wsdlGetForecasts

6.3 wsdlUpdateForecasts

6.5 wsdlGetMonthlyView

6.6 wsdlUpdateForecastV2

6.8 wsdlUpdateForecastsV3

6.4 wsdlGetSalesData

6.9 wsdlGetSalesDataV2

6.7 wsdlGetOptimalStaffing

4.6 wsdlUpdateAdminGroupRelationships <- not applicable for Quinyx WFM

Click here to view the new Quinyx WFM Web Service documentation. You can find even more web services info here.
We encourage all our customers to make use of our APIs to maintain data and make sure that information is up to date. To ensure scalability of our APIs while growing our customer and user base, we have decided to add restrictions on usage of our SOAP APIs. These restrictions will be enforced programmatically and means that we will enforce a limit on concurrent calls per customer to 10. You should expect response code 429 if you happen to exceed this limit and you are recommended to implement a backoff-retry mechanism to handle the limit. Note that the limit applies to SOAP only. When moving from SOAP to Rest over the following years, any limits will be built into the API. Please make sure to forward this information to the party within your company responsible for integrations.

How Did We Do?