Rule logic

The primary goal of the Scheduled Swipes Rule is to create individual records for each swiping event an employee is expected to record. For example, an employee scheduled to work from 0800-1700 with a meal break occurring from 1200-1300 has four “scheduled” swipe events:

  1. An ON swipe event at 08:00
  2. A Meal Start swipe event at 12:00
  3. A Meal End swipe event at 13:00
  4. An OFF swipe event at 17:00

Initially, the rule generates these scheduled swipe records as follows:

  • In the absence of any real (actual) swipes, the rule generates one scheduled swipe record for each expected swiping event. This means either:
    • An ON and an OFF (order types 1 and 4)
    • An ON, a TCODE=MEAL, a TCODE=WRK, and an OFF (order types 1, 2, 3, and 4)

    The timestamp of the scheduled swipe matches the scheduled time of the expected swiping event (the employee's schedule).

  • The rule supports the use of any time code set as "is break" to identify a scheduled meal.
  • If an employee is not scheduled, scheduled swipes will not be created.
  • If an employee's schedule is edited, the rule, when re-executed, re-evaluates the new/updated scheduled swipe events. The rule then updates the associated scheduled swipe records accordingly.
  • Each scheduled swipe record has an IS_REAL flag in your database. When the record is initially created, this flag is set to false, indicating that the swipe record reflects the employee's schedule and not any actual clocking that the employee has recorded. This flag helps determine if the scheduled swipe is displayed for confirmation/correction on the HTML Clock.

Whenever a real swipe is processed onto an employee's timesheet, the rule should re-execute (ensure the recalculation settings of your calculation groups are configured to support this). During re-evaluation, the IS_REAL database flag on the scheduled swipe record that corresponds to the real clock is updated to true. The timestamp of the record is also updated to reflect the timestamp of the corresponding real swipe. The rule also attempts to determine if the other scheduled swipes for the day require updating. The update logic is as follows:

  • Relative order must be maintained. Therefore, the expected sequence of 1, 2, 3, 4 (or 1, 4 if no meal is scheduled) cannot be broken. A collection of scheduled swipes for a single charge date will not support a situation in which the chronological timestamps of real swipes conflict with the expected sequence of scheduled swipes. When this occurs, the rule will remove all scheduled swipe records for the day and unauthorize the day.
  • A scheduled swipe is assigned a suggested time if the scheduled swipe can be placed within the expected 1, 2, 3, 4 sequence. If it cannot (for example, a scheduled Meal Start swipe would have a time after an actual OFF swipe), the impacted scheduled swipe record is updated with a blank time value. In this case, the system cannot definitively determine a time that it "should have" occurred because of what has occurred.
  • For an ON swipe, the only possible suggested time is the scheduled ON time.
  • For an OFF swipe, the only possible suggested time is the scheduled OFF time.
  • For a meal-related swipe, the suggested time is automatically updated if the complimentary meal-related swipe is real and the scheduled swipe will continue to fall within the relative order constraint. For example, if an employee scheduled to take a meal break from 12:00-13:00 records an actual meal start at 12:13, the rule will update the scheduled meal end time to 13:13 (the actual meal start time plus the scheduled duration).
    Note: If the start meal break and end meal break swipes are both missed and the start meal break is edited to be later than originally scheduled, the end meal break will not be automatically adjusted during edit to reflect the late start. However, once the start meal break edit is updated in WFM, an adjustment to the end meal break is reflected.

    If updating the scheduled time would break the relative order constraint, the scheduled swipe is updated with a null timestamp, ensuring that it will still be eligible for presentation and confirmation/correction at the HTML Clock. In this case, a "suggested" time is not presented to the employee.