Results for “pay_calendars_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PAY_CALENDARS_V is an Oracle E-Business Suite view owned by the APPS schema within the Payroll (PAY) product module. It is classified in the ETRM metadata as a user-interface support object, meaning its primary purpose is to present calendar definition data in a form suitable for Oracle Forms-based screens, self-service pages, and related front-end components rather than to serve as a standalone business entity. The view is documented as VALID and is available in both the 12.1.1 and 12.2.2 releases.

Functionally, the view exposes the configuration of payroll period calendars, which define the fiscal and processing periods used by payroll runs, costing, and period-to-date balances. By joining the base calendar definition to the time period type definition, the view resolves internal period type codes into a user-friendly display name and surfaces the number of fiscal periods per year. This makes it a convenient, denormalized access point for reporting and integration queries that need calendar context without navigating multiple base objects. Because it is a view rather than a table, no direct DML should be performed against it; changes to calendar data must occur through the underlying PAY_CALENDARS table and standard application flows.

Underlying Base Objects

The view is defined over two documented base objects:

• PAY_CALENDARS (referenced via a SYNONYM) — the primary base object holding calendar definitions, including the period set name, actual and processing period types, start date, descriptive comments, descriptive flexfield attributes, and standard WHO audit columns.
• PER_TIME_PERIOD_TYPES_VL (a VIEW) — a translated, view-layer object that supplies the display name for a given period type.

The join condition is TPT.PERIOD_TYPE = CAL.ACTUAL_PERIOD_TYPE, which attaches the human-readable period type description to each calendar row. The view also generates a ROW_ID using CAL.ROWID, a common EBS Forms pattern that provides a unique row identifier for the user interface layer. The presence of the VL (view layer) base object indicates that the display period type is translation-aware, so the value returned respects the session language where translations exist.

Key Columns

• ROW_ID — Surrogate row identifier derived from the PAY_CALENDARS ROWID; used by the Forms user interface.
• DISPLAY_PERIOD_TYPE — The translated, user-facing name of the period type, sourced from PER_TIME_PERIOD_TYPES_VL.
• PERIOD_SET_NAME — The accounting period set with which the calendar is associated.
• ACTUAL_PERIOD_TYPE — The period type used for the calendar's actual periods (join key to the period type view).
• PROC_PERIOD_TYPE — The period type used for processing periods, which may differ from the actual type.
• START_DATE — The effective start date of the calendar definition.
• COMMENTS — Free-text description of the calendar.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 — Descriptive flexfield (DFF) context and segment columns.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — Standard WHO audit columns.
• NUMBER_PER_FISCAL_YEAR — The count of fiscal periods per year for the associated period type, sourced from PER_TIME_PERIOD_TYPES_VL.

Common Use Cases and Queries

Typical scenarios include validating calendar setup before a payroll run, extracting period type mappings for interfaces and conversions, and building period-to-date reporting that requires fiscal period counts.

List all calendars with their display period type:

• SELECT period_set_name, display_period_type, actual_period_type, proc_period_type, start_date FROM apps.pay_calendars_v ORDER BY period_set_name;

Retrieve calendars for a specific period set with fiscal period counts:

• SELECT period_set_name, display_period_type, number_per_fiscal_year FROM apps.pay_calendars_v WHERE period_set_name = :p_period_set;

Because the view is intended for user-interface support, it is best used for read-only querying. For high-volume batch processing, querying the base PAY_CALENDARS table directly may be preferable to avoid the join overhead.