Period IDs
Overview
Period IDs define the begin date, end date, and frequency context for a processing period. Calendars point to period IDs, so a weak period setup propagates directly into accumulator behavior, payment timing, retro scope, and frequency conversion.
Period Creation Flow
Pages And Components
| Purpose | Component / page |
|---|---|
| Define one period manually | GP_CALENDAR_PERIOD |
| Generate many periods | GP_AUTO_PRD |
| Typical navigation | Global Payroll & Absence Mgmt > Absence and Payroll Processing > Define Calendars > Periods |
Key Fields
| Field | Purpose |
|---|---|
| Period Begin Date | Start of the processing period |
| Period End Date | End of the processing period |
| Frequency | Weekly, biweekly, semimonthly, monthly, and similar definitions |
| Frequency Factor | Supports annualization and deannualization logic |
Common Frequency Setup
| Frequency | Unit of Measure | Units in Period | Typical use |
|---|---|---|---|
| Weekly | Day | 7 | Standard weekly payroll |
| Biweekly | Day | 14 | Two-week payroll cycle |
| Semimonthly | Month-pattern based | 2 per month | 1st-half / 2nd-half payroll |
| Monthly | Month | 1 | Salaried monthly payroll |
| Quarterly | Month | 3 | Bonus or tax-specific patterns |
Why Frequency Matters
Oracle's payroll documentation makes period frequency more than a label. The frequency is used to deannualize elements that are defined with a frequency but without a generation control frequency. Once generation control frequency is introduced, the engine compares the element's frequency, the generation control frequency, and the pay period frequency to decide whether an amount resolves, deannualizes, or is skipped.
In practice, this means a period definition can change resolved values even when the earning formula did not change.
Automatic Period Creation
GP_AUTO_PRD is the standard way to generate multiple periods. It is efficient for recurring production calendars, but it still requires review at year boundaries, short months, leap years, and any payroll that has country-specific year-end timing rules.
Operational Rules
- Once processing begins, do not edit period fields unless you cancel the pay run.
- Keep payment date decisions on the calendar, not the period. Multiple calendars can reuse the same period with different payment dates.
- Align pay group design with period frequency to avoid avoidable calendar proliferation.
Accumulator Impact
Period dates influence accumulator assignment when a balance is based on period begin date, period end date, or payment date. That means period errors frequently surface later as balance discrepancies rather than immediately as calendar errors.
Key Takeaways
- Period IDs are reusable runtime anchors, not one-off date records.
- Frequency setup influences both selection logic and calculation amounts.
- Review period definitions before mass calendar creation, not after the first failed payroll.