Rule overview

Requiring a real clock to generate scheduled swipes

You can configure the Scheduled Swipes Rule to require at least one actual clock to be present on a day before the scheduled swipe records will be generated. In this configuration, a day with zero real clocks is considered to be a Failed-To-Report situation that prohibits an employee from confirming/correcting their full collection of missed swiping events.

Creating timesheet clocks based on scheduled swipe records

In addition to creating scheduled swipe records for confirmation/correction on the HTML Clock, the rule can also create system-generated clocks on the timesheet itself. When enabled, this allows the system to automatically pay an employee to schedule even if that employee has failed to record all of their expected swipes.

Note: Timesheet clocks are only ever generated for scheduled swipe records that have a timestamp. If the timestamp of a scheduled swipe record is null, an associated timesheet clock will not be generated.

Removing stale scheduled swipe records

For employees who are no longer required to correct missed swipe events, you can configure the rule to remove existing scheduled swipe records. In this configuration, when the rule executes, any existing scheduled records on the current day are removed.

For example, a once-eligible employee can become ineligible for scheduled swipes in these scenarios:

  • The employee no longer satisfies the condition configured in the rule. For example, an organization may require only part-time employees to use scheduled swipes. When a part-time employee becomes a full-time employee, their old scheduled swipe records are removed from the application.
  • The employee moves to a calculation group that does not use scheduled swipes. For example, an organization may require employees in the CALIFORNIA calculation group to use scheduled swipes, but not employees in the NEVADA calculation group. When an employee moves from the CALIFORNIA calculation group to the NEVADA calculation group, their old scheduled swipe records are removed from the application.

Editing clocks directly on the timesheet

If a user edits clock values directly on the timesheet through an override, the rule will no longer generate scheduled swipes. When clock edits are applied to the timesheets, the rule defers to these edits and considers them to be the true values as desired by the user who performed the edits. Any remaining system-generated clocks become “real” clocks when a user edits the timesheet directly.

Automatic unauthorization of timesheets

When these situations occur, the rule unauthorizes the day and removes all scheduled swipe records from the day:

  • If an unexpected clock type is encountered.
  • If actual swipes are chronologically ordered out of the expected relative order. For example, OFF clock followed by a Meal Start clock on a single charge date.
  • If extra swipes are encountered. For example, two ON clocks on a single charge date.

Rule location

Within the Quick Rule Editor, the Scheduled Swipes Rule should be configured at the “Rounding Clocks” execution point. If a Clock Rounding Rule is also configured within the calculation group, the rule should immediately follow that rule.

Scheduled swipes log

Because the Scheduled Swipes Rule manipulates scheduled swipe records based on the absence or presence of actual clocks, a separate log table has been created. You can use the scheduled swipes log to view the full history of scheduled swipe records for any given day/employee. Logged scheduled swipe records are found in the SS_SCHEDULED_SWIPE_LOG table.