Search Results pay_assignment_actions_pkg




Overview
Explore in AI Chat

Overview

PAY_ASSIGNMENT_ACTIONS_PKG is a core PL/SQL package in the APPS schema of Oracle E-Business Suite (documented as VALID in both 12.1.1 and 12.2.2). It encapsulates the business logic governing assignment actions within Oracle Payroll — the transactional records that link a payroll action to a specific employee assignment, and which carry the action's processing state, payment state, and messaging outcomes.

The package is classified as an OTHER API rather than a public, supported interface, signifying that it is intended primarily for internal use by Oracle Payroll processing engines, views, and payroll-related packages. It centralises row-level manipulation (delete and lock), retrieval and maintenance of action statuses, payment status lookup, message-line validation, and archival of start dates on assignment actions and persons.

Key Procedures and Functions

The 12.2.2 documented interface exposes twelve procedures and functions:

  • DELETE_ROW — removes an assignment action record.
  • LOCK_ROW — obtains a row-level lock on an assignment action, protecting it from concurrent modification during payroll processing.
  • GET_ACTION_STATUS — returns the current action status for an assignment action.
  • ENABLE_ACTION_STATUS and DISABLE_ACTION_STATUS — activate or deactivate a given action status, controlling whether an action may transition into that state.
  • ACTION_STATUS_ENABLED — tests whether a specific action status is currently enabled.
  • GET_PAYMENT_STATUS_CODE — retrieves the payment status code associated with an assignment action.
  • GET_PAYMENT_STATUS — returns the derived payment status (typically the decoded or descriptive form of the status code).
  • MESSAGE_LINE_EXISTS — determines whether a payroll message line already exists, supporting idempotent message generation and duplicate suppression.
  • ARCHIVE_ASSIGNMENT_START_DATE — preserves the start date of an assignment action for archival or auditing purposes.
  • ARCHIVE_PERSON_START_DATE — preserves the start date of a person record for archival or auditing purposes.
  • FOR — a documented identifier, conventionally a cursor or loop construct used internally by the package body, listed among the documented subprograms.

These subprograms form the operational toolkit for reading and mutating assignment-action state without requiring callers to write directly against the underlying base tables.

Tables Accessed

The package references its tables through APPS synonyms:

  • PAY_ASSIGNMENT_ACTIONS — the primary entity; holds assignment actions and their statuses, deleted and locked by this package.
  • PAY_ACTION_INTERLOCKS — enforces sequencing and interlock constraints between related payroll actions.
  • PAY_PAYROLL_ACTIONS — the parent payroll action header to which assignment actions belong.
  • PAY_MESSAGE_LINES — queried by MESSAGE_LINE_EXISTS to detect existing messages.
  • PER_ALL_ASSIGNMENTS_F and PER_ALL_PEOPLE_F — dated HR assignment and person records used to validate and archive assignment and person start dates.
  • DUAL — used for single-row expressions and validations.

Usage Notes

PAY_ASSIGNMENT_ACTIONS_PKG is invoked predominantly by Oracle Payroll internals. ETRM records that it is referenced by ten other packages, including PAY_SA_PAYMENT_STATUS_PKG, PAY_CA_RULES, PAY_AE_PAYROLL_REGISTER, and PAY_KW_PAYROLL_REGISTER, and appears in the definitions of views such as PAY_ASSIGNMENT_ACTIONS_V, PAY_PRE_PAYMENTS_V, PAY_VOIDABLE_ASG_ACTIONS_V, PAYBV_PAYROLL_MESSAGE_V, PAY_KR_SEP_HISTORY_V, and the PAY_US_EMPLOYEE_PAYSLIP_WEB page. It is therefore exercised implicitly during payroll run processing, prepayment and voiding operations, payslip generation, and country-specific payroll registers.

Because the package is classified OTHER rather than a supported public API, custom code should avoid direct calls where an alternative public API exists. When custom extensions must reference it — for example, to lock or query assignment-action status — they should treat the interface as subject to change between releases and perform a dependency check against the APPS schema before use.