Calendars
Overview
The calendar is the primary runtime object in Global Payroll. It ties together who is processed, what kind of run is being executed, and the period and payment date context for the run.
Calendar Definition Components
What A Calendar Controls
- Population through pay group and selection criteria
- Process intent through run type
- Time scope through period ID and payment date
- Runtime exceptions through overrides, exclusions, target calendar, and special retrieval options
Creation Options
| Option | Component | Best use |
|---|---|---|
| Single calendar | Calendars component | Manual setup and targeted exceptions |
| Set of calendars | GP_AUTO_CAL1 | Repeating production calendars across periods |
Oracle documentation also notes that automatically created calendars can still be edited in the regular Calendars component afterward.
Payee Selection Patterns
The calendar page is not just a header. It is also where payee selection behavior becomes operational:
- active-only populations for standard production
- active-plus populations that include payees with pending positive input
- active-plus populations that include payees with pending retro triggers
- listed payees only for one-payee or small-group processing
If you use the listed-payee approach, you can keep adding payees to the list while the calendar remains open. For partial-period cases, the calculate-thru date can be used to stop processing at an earlier segment end date.
Operational Fields That Are Easy To Miss
| Field or behavior | Why it matters |
|---|---|
| Target Calendar | Required when an absence run or other run feeds another calendar |
| If Payment Date is a Holiday | Determines whether the pay date moves before, after, or not at all |
| Time and Labor payable-time period | Controls which payable time is pulled for a run |
| Excluded Elements | Lets you suppress specific element resolution for a calendar |
If a calendar feeds another calendar, create the target calendar first. Oracle's setup guidance is explicit on that point for both manual and automatic creation.
Overrides
Calendar-level overrides are powerful because they change runtime behavior without cloning foundational configuration. They are also risky because they can make one calendar materially different from another calendar that appears similar on paper.
After processing begins, do not edit calendar, period, run type, or calendar group fields unless you cancel the pay run. The calendar should be treated as operationally locked once Identify has started.
Naming Convention
Use a readable standard such as THA-MON-2026-01-PAY or THA-MON-2026-01-ABS so support teams can infer pay group, period, and process intent immediately.
Key Takeaways
- Calendars are the assembly point for pay group, run type, period, and payment logic.
- Selection criteria and listed payees can materially change the processed population.
- Target calendars and holiday payment rules should be reviewed before the first production run.