Search Results pay_payact_pkg




Overview
Explore in AI Chat

Overview

The APPS.PAY_PAYACT_PKG package is a PL/SQL utility package within the Oracle E-Business Suite Payroll (PAY) module. It operates against the assignment action and payroll action schema and is classified as an OTHER API in the ETRM object registry. Its primary business function is to support the creation, sorting, and retrieval of assignment-level actions generated during payroll processing. Assignment actions represent the discrete steps the payroll engine executes for each assignment, while payroll actions represent the higher-level run that triggers them. This package provides the procedural glue that populates and orders those actions, and supplies parameter lookup values used by the surrounding payroll processing logic.

The package resides in the APPS schema, carries a documented status of VALID, and depends only on SYS.STANDARD. Its documented API surface is deliberately small, comprising four program units. It is not a publicly referenced package — the ETRM metadata records zero packages referencing it — which indicates it is an internal helper invoked by the payroll action engine rather than a general-purpose integration point.

Key Procedures and Functions

  • RANGE_CURSOR — Defines and drives the query cursor used to select the set of assignment actions within a processing range. It establishes the working set that the remaining procedures operate upon, typically scoped by payroll action or assignment range.
  • ACTION_CREATION — Responsible for creating assignment action rows during payroll processing. This is the core write operation of the package, generating the action records that the payroll engine subsequently executes or evaluates.
  • SORT_ACTION — Orders the actions within a processing set so they are handled in the correct sequence. Payroll actions must be processed in a defined order to respect dependencies between assignment-level steps, and this procedure enforces that ordering.
  • GET_PARAMETER — Retrieves a configuration or parameter value required by the action-processing logic. It abstracts the lookup so that callers obtain required settings without embedding direct queries in their own code.

No parameter signatures are documented in the ETRM metadata. The procedures should be treated as internal implementation details; direct invocation from custom code is not advisable without validating the signature against the deployed package source.

Tables Accessed

  • PAY_ASSIGNMENT_ACTIONS — The primary table of assignment-level actions. The package reads and writes here to create and enumerate the actions being processed.
  • PAY_ASSIGNMENT_ACTIONS_S — The translated or secondary table for assignment actions, used to supply descriptive or language-dependent attributes associated with each action.
  • PAY_PAYROLL_ACTIONS — Provides the parent payroll action context that scopes a given run and ties individual assignment actions to the payroll action that generated them.
  • PER_ALL_ASSIGNMENTS_F — The HR assignments date-tracked table, consulted to resolve assignment details and validate the assignments against which actions are created.
  • DUAL — Used for single-row expression evaluation and parameter defaults.

All table references are made through APPS synonyms, consistent with the package's ownership in the APPS schema.

Usage Notes

PAY_PAYACT_PKG is an internal payroll processing utility rather than a customer-facing API. It is most commonly invoked indirectly by the payroll action engine and related concurrent processing during a payroll run, when assignment actions are generated, ordered, and parameterized. Because the ETRM records no dependent packages and no public references, integrators should not build custom interfaces directly against these procedures; signature changes between releases are unguarded by a documented API contract.

Where custom extension is required, the recommended approach is to read the resulting data from PAY_ASSIGNMENT_ACTIONS and PAY_ASSIGNMENT_ACTIONS_S after processing, rather than calling the package directly. Behavior is consistent across Oracle EBS 12.1.1 and 12.2.2 in terms of object status (VALID) and schema placement (APPS). Developers should confirm the live package specification in their target instance before relying on any procedure name or parameter, as the ETRM documentation for this object is limited to the four program units listed above.