Search Results pay_run_type_usages




Overview
Explore in AI Chat

Overview

The PAY_RUN_TYPE_USAGES view is a public, date-effective view owned by the APPS schema in Oracle E-Business Suite Payroll (PAY). It exposes the run type usage hierarchy that governs how payroll run types are composed and sequenced relative to one another. In EBS, a run type usage defines a parent-child relationship between two run types, allowing one run type to include, trigger, or otherwise be associated with a child run type during payroll processing. Because this relationship is date-tracked, the view returns only the rows that are effective as of the session's effective date.

The object is classified as a VIEW with status VALID and is documented as a "Date effective view." Its primary role is to provide a datetracked, session-aware projection of the underlying datetrack entity so that reports, concurrent programs, and integrations always see the currently effective configuration rather than historical or future-dated definitions. This makes it particularly suitable for payroll reporting, configuration audits, and integration extracts that must respect effective-dating semantics.

Underlying Base Objects

The view is defined over a single documented base object, PAY_RUN_TYPE_USAGES_F, accessed via a synonym. The _F suffix designates the datetrack (date-effective) base table, which stores all historical, current, and future-dated versions of each run type usage relationship. The view filters this table so that only rows whose effective date range encompasses the current session effective date are returned.

The effective-date comparison relies on FND_SESSIONS (also referenced via synonym), from which the view obtains the session's EFFECTIVE_DATE for the current USERENV('SESSIONID'). This is the standard Oracle EBS pattern for datetracked views, ensuring that two users with different effective dates see different slices of the same underlying data. Both referenced objects are documented in the ETRM metadata for release 12.2.2, and the same view structure is consistent with 12.1.1.

Key Columns

  • RUN_TYPE_USAGE_ID — Primary identifier for the run type usage record.
  • PARENT_RUN_TYPE_ID — Identifies the parent run type in the relationship; links to the run type definition that contains or initiates the usage.
  • CHILD_RUN_TYPE_ID — Identifies the child run type that is referenced or included by the parent.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — The datetrack range defining when the usage relationship is active. The view returns only rows where the session effective date falls within this range.
  • BUSINESS_GROUP_ID — The business group (legislation/enterprise) that owns the run type usage, enforcing multi-tenant separation.
  • LEGISLATION_CODE — The legislation under which the run type usage is defined, supporting country-specific payroll behavior.
  • SEQUENCE — Controls the ordering in which child run types are processed or presented relative to the parent.
  • OBJECT_VERSION_NUMBER — Optimistic locking column used by the underlying entity.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — Standard EBS audit columns tracking creation and modification.

Common Use Cases and Queries

This view is commonly queried to audit run type composition, to drive custom payroll reports, and to validate configuration migrations between environments. A typical query lists effective usages for a given business group:

  • Identify all child run types associated with a specific parent run type, ordered by SEQUENCE.
  • Report the current effective configuration for a business group and legislation.
  • Compare parent-child relationships across business groups for consolidation analysis.

Sample SQL:

SELECT rtu.run_type_usage_id, rtu.parent_run_type_id, rtu.child_run_type_id,
       rtu.sequence, rtu.business_group_id, rtu.legislation_code
  FROM apps.pay_run_type_usages rtu
 WHERE rtu.business_group_id = :p_business_group_id
    AND rtu.parent_run_type_id = :p_parent_run_type_id
 ORDER BY rtu.sequence;

Because the view is session-datetracked, no explicit SYSDATE predicate is required; the effective date is derived automatically from FND_SESSIONS. For historical or future-dated comparisons, developers should query the _F base table directly using an explicit effective date.