Skip to main content

Calendar Groups

Overview​

Calendar groups are the run-control unit for batch processing. They determine which calendars run together, in what order, and under one processing decision cycle from Identify through Finalize.

Calendar Group Assembly​

Creation And Navigation​

PurposeComponent / page
On-cycle calendar groupingGP_CALENDAR_RUN
Off-cycle groupingGP_CALENDAR_RUN from off-cycle navigation
Typical navigationGlobal Payroll & Absence Mgmt > Absence and Payroll Processing > Define Calendars > Calendar Groups

Why Sequence Matters​

The order of calendars in the group determines the calculation sequence. If absence results must feed payroll, absence calendars normally belong earlier in the sequence than their payroll targets. The same logic applies to supplementary or bonus processing that depends on prior output.

Group Design Rules​

RuleRationale
Group calendars that need identical phasesThe selected processing phases run across the whole group
Do not mix countries in one groupCalendars from different countries cannot be processed together
Sequence dependency-sensitive calendars firstPreserves result dependencies
Keep off-cycle scenarios separate when possibleSimplifies approvals and audit review

Open Calendar Group Behavior​

Oracle describes a calendar group as open from the time Identify runs until Finalize completes. That matters because:

  • a payee can be selected in only one unfinalized calendar group at a time
  • if the same payee is picked up by a second open group, the second run will error
  • to process the second run, you generally finalize the first group or suspend the payee in the first group and recalculate

This is one of the most important operational rules in the entire framework.

Template And Stream Considerations​

Calendar groups can also be marked for use as templates for online forecasting or balance inquiry. If stream processing is needed, the stream option is configured at the calendar group level and then used on run control.

Key Takeaways​

  • Calendar groups are orchestration objects, not just containers.
  • Open-group rules directly affect special runs and bonus timing.
  • The safest design is to make dependencies explicit in the sequence rather than rely on operator memory.