This post explores an Off-Cycle design pattern for scenarios where automatic resolution of selected “downstream” Elements is required.
To facilitate automatic processing it is necessary to use the Off-Cycle, Element Selection “ALL” option.

However, using the “ALL” setting may result in resolution of unwanted elements. This post describes a solution using Generation Controls to govern Off-Cycle processing, enabling automatic resolution of selected Elements and minimizing manual data entry via Positive Input.
Firstly, let’s examine some common Off-Cycle scenarios:
- Late Hire Payment, where an employees’ hire falls within the previous pay period but was not entered into the system until after the previous pay was finalized. The “Correction” Off-Cycle Type enables processing of the employees’ first pay, rather than waiting for retrospective payment in the current pay period.
- Early Termination Payment, where an employees’ termination falls within the current open pay period but cannot wait for the On-Cycle to be finalised. The “Advance” Off-Cycle Type allows the employees’ termination to be processed prior to the On-Cycle pay process.
- Missed Payment, where a transaction/s was missed in the previous pay period and the payment cannot wait for retrospective processing in the current pay. The “Correction” Off-Cycle Type facilitates processing of missed payments prior to finalisation of the current/open pay.
In the above scenarios there may be several automatically resolved “downstream” Elements required, such as:
- Tax Deductions
- Superannuation/Pension Deductions
- Entitlement Payouts (ie. termination payments)
- GL Accruals
Equally, there may be Elements that resolve automatically that are not required. This is especially true for “Correction” Off-Cycles, where Elements such as regularly occurring Deductions are not required, as it would result in under and/or over payments. For example, a recurring Union Deduction (entered via Element Assignment) would have been processed in the prior On-Cycle being corrected, so would not be required in the Off-Cycle.
This design leverages 2 System Elements to govern Off-Cycle behavior:
“OFF CYCLE” System Element indicates whether the current segment is an Off-Cycle:

The “GP TX TYPE” System Element indicates the Transaction Type, as one of the following values:
- “A” – Advance Off=Cycle
- “M” – Manual Payment
- “R” – Correction Off-Cycle
- “U” – Unscheduled Payment
- <Blank> – regular On-Cycle

The “OFF CYCLE” and “GP TX TYPE” System Elements can be used in a Generation Control Formula to prevent processing of an Earning or Deduction in a Correction Off-Cycle:

Not all Earnings and Deductions require the Generation Control logic. Selecting Elements to exclude from Off-Cycle processing is based on the following factors:
- Is the Element configured for “Payee” level override? If so, the element can be applied by Element Assignment in which case it will be included for processing in an Off-Cycle Calendar.

- Is the Calculation Rule comprised of components that will resolve automatically (ie. not “Payee Level”)

- Is the Earning/Deduction required in an Off-Cycle? As mentioned, some “downstream” Earnings and Deductions are required in an Off-Cycle.
Typically, 1/3 of Earnings and Deductions will require Generation Control logic to prevent processing in Correction Off-Cycles. Where an Element has an existing Generation Control, the existing configuration will need to be updated or cloned and updated.
Whilst this pattern requires widespread configuration changes, it minimizes manual entry, but still allows the flexibility of using Positive Input to override Generation Control logic if required.