Attendance exception rules can be linked to a Pay Policy, so a rule only applies to the employees on that policy rather than to everyone. This lets you run different compliance checks for different groups of staff, for example stricter rules for one policy and lighter rules for another. When a change that starts from a past date affects which rules apply to an employee, the system marks the out-of-date exceptions as Invalid and raises new exceptions using the rules that now apply.

Link Exception Rules to a Pay Policy

Step 1 - Go to Attendance → Configurations → Pay Policies and open the Pay Policy you want to configure.

Note: Only the System Admin can add, edit, or delete a Pay Policy, including the exception rules linked to it. The HR Admin can view the Pay Policy screens but cannot change them.

Step 2 - On the Pay Policy page, expand the Link Attendance Exception Rules section.

Step 3 - Choose the exception rules that should apply to employees on this Pay Policy. You can add new rules or remove rules that are already linked.

Step 4 - Click Save. The Save Changes window opens.

Step 5 - Select the Effective Date, complete the other details in the window and click Save Changes. The linked rules apply from that date.

• You can choose only the start date of the immediate previous pay period, the current pay period or a future pay period. Older dates are shown but cannot be selected.
• If a version with the same effective date already exists, saving overwrites that version.
• One save stores every change made on the Pay Policy page as one version, not only the change to the linked rules.

For more on effective dates and versions, refer to How to Set up Pay Policies.

Note: When Pay Policies are enabled, an exception rule is evaluated only for employees assigned to a Pay Policy that is linked with the rule. An employee who is not assigned to any Pay Policy does not get any exceptions.

Change the Linked Rules on an Existing Version

You can also add or remove linked exception rules on an existing version from the Pay Policy Version History screen by clicking the edit icon on that version. The effective date cannot be changed here; it stays as the version's own date. Saving starts the same recheck as saving from the Pay Policy page, but only for the dates that version covers. A version applies only until the next version starts, so the recheck stops the day before the next version's effective date.

Note: Versions with an effective date older than the start of the immediate previous pay period can only be viewed, never edited.

How Exceptions Are Rechecked When a Past-Dated Change Is Saved

When you save a change that starts from a past date and affects which exception rules apply to an employee, the system rechecks the exceptions for the dates the change covers. This keeps the Exception Records screen in line with the rules that actually applied on each day.

Changes that start a recheck

• Adding or removing a linked exception rule on a Pay Policy version, from the Pay Policy page or from Pay Policy Version History. Only the rules that were added or removed in that save are rechecked. This affects every employee assigned to that Pay Policy.
• Assigning a different Pay Policy to an employee, or removing their Pay Policy assignment, with a start date in the past. All exception rules are rechecked for that employee.
• Changing the employee's employment record with a past date: terminating an employee, rehiring a terminated employee, adding a new employee whose joined date is already in the past, or correcting a joined date or termination date. All exception rules are rechecked for that employee.

Changes that do not start a recheck

• Saving a Pay Policy version without adding or removing a linked exception rule, for example changing only Round-Off Rules, Break Rules, Pay Codes, the Additional Rules section or the View Actual Time setting.
• Changes with a future effective date, such as a version effective next pay period or a future termination date. Ticking Terminate Now also does not start a recheck.
• Deleting a Pay Policy or deleting a future-effective version. A deletion applies immediately and causes no recalculation. A deleted Pay Policy is shown with "(Deleted)" after its name in the Exception Records filter, so you can still filter the exceptions created under it.
• Terminating and rehiring an employee on the same day or the next day.
• Editing an exception rule's own settings on the Exception Rule Configuration screen. The new settings apply only to attendance evaluated from then on.
• Changes to roster shifts, work schedules, leave, holidays, punch records (including imported records), the working week or the Attendance Calculation Basis. These follow the normal behaviour: an exception that no longer applies is marked Resolved.

Which dates are rechecked

• Start = the change's effective date. For a termination, it is the day after the termination date. If that date falls inside an attendance sheet that is already approved for the employee, the recheck starts the day after that sheet ends. This is worked out for each employee separately, so two employees affected by the same change can have different start dates.
• End = today. If you change a version that is followed by a later version, the recheck ends the day before the later version's effective date. If you correct a joined date or termination date, only the days between the old date and the new date are rechecked.
• Future dates are never rechecked.
• Dates inside an approved attendance sheet are never changed. Their exceptions keep their current status.

What happens to each exception

• Exceptions affected by the change = every exception in the rechecked dates that was raised by an affected rule is marked Invalid, whatever its status was: Pending, Acknowledged or Resolved. The system does not check each one to see whether it still applies. Invalid exceptions are never deleted; they are kept as history and can be viewed by ticking Show Invalid Exceptions in the Exception Records filter. They cannot be acknowledged, edited or selected.
• Exceptions already marked Invalid = left exactly as they are. An Invalid exception never goes back to Pending, Acknowledged or Resolved, even if a later change (such as a rehire) means the employee was employed on that date after all.
• New exceptions = the system then checks each rechecked date against the rules that now apply and raises a new Pending exception for every affected rule that is broken. This happens even if the old exception for the same rule and date had been acknowledged or resolved, so it needs to be reviewed again.
• Exceptions from rules that were not affected = keep their status and stay on the tab they are on. A single date can show both Invalid exceptions and live exceptions.
• Actions already taken = are not undone. Assigned leave, edited attendance records and changed roster shifts stay as they are and are used in the recheck, so the same problem may not be raised again. An exception that was only acknowledged is raised again as a new Pending exception.

What the system creates depends on the change:

• Rule removed from a version = the removed rule's exceptions are marked Invalid. Nothing new is created.
• Rule added to a version = nothing is marked Invalid. New exceptions are created for the added rule only.
• Employee moved to a different Pay Policy = all exceptions in the rechecked dates are marked Invalid, then new exceptions are created using the rules linked to the new Pay Policy.
• Pay Policy assignment removed, past termination date, joined date moved later or termination date moved earlier = exceptions are marked Invalid. Nothing new is created, because the employee had no Pay Policy or was not employed on those dates.
• Rehire, joined date moved earlier, termination date moved later, or new employee with a past joined date = new exceptions are created for the dates the employee was employed.

When it happens

• While you save = the affected exceptions are marked Invalid and the Audit Trail entry is written. You see the Invalid exceptions as soon as the save finishes.
• After you save = new exceptions are created by a background process, so you do not have to wait for them. Until it finishes, some dates may not show their new exceptions yet, and the tab counts show what exists at that moment.
• An attendance sheet that covers a date still waiting for this background process cannot be approved until it finishes. If a sheet is approved before the process reaches it, no new exceptions are created for its dates.

Note: When you upgrade to 8.2.1, the system rechecks existing exceptions once, from the start of the immediate previous pay period up to the upgrade date. Exceptions that no longer match the employee's Pay Policy assignment, the linked exception rules or the employment record are marked Invalid, and missing exceptions are created as Pending. This runs in the background, and exceptions inside approved attendance sheets are not changed.

Audit Trail

Each time exceptions are marked Invalid, the system records it in the Audit Trail for the Attendance module under the action Invalidate Exception.

• One entry is created for each employee who had at least one exception marked Invalid. All entries from the same save share the same date and time, reason and affected period.
• The Action Owner is recorded as the System, and the entry shows the screen where the change was saved, such as Employee Job, Edit Pay Policy or Pay Policy Version History.
• The description shows the reason (for example, "Pay Policy assignment changed from `California Pay Policy` to `New York Pay Policy`." or "Employment terminated with a past termination date."), the affected period, any dates not changed because an attendance sheet was approved, the number of exceptions marked Invalid and a count for each exception rule.
• The affected period shows the dates that were actually marked Invalid, so it can start later than the effective date you chose.
• A later change creates a new entry. Existing entries are never overwritten.

To review and act on exceptions, refer to How to Review and Act on Attendance Exception Records.