Search Results pay_ter_upd




Overview
Explore in AI Chat

Overview

The APPS.PAY_TER_UPD package body is a server-side PL/SQL component within the Oracle E-Business Suite Payroll (PAY) module. Its name follows the Payroll terminology naming convention in which the TER prefix denotes "Termination" processing. The package provides the update-oriented logic used by the Termination business layer, responsible for persisting changes to termination records held against employee assignments within Oracle HRMS and Oracle Payroll.

In Oracle EBS 12.1.1 and 12.2.2, the Payroll termination framework is split across several cooperating units: PAY_TER_BUS (business rule validation and orchestration), PAY_TER_SHD (shadow/record-copy handling used during date-tracked updates), and PAY_TER_UPD, which carries out the physical write operations against the underlying payroll tables. The package body is owned by the APPS schema and is documented as VALID in the ETRM repository, confirming it is a shipped, production component rather than a customisation. Its API classification is recorded as OTHER, and it is not referenced by any other database object, indicating that it sits at the bottom of the call hierarchy as a leaf-level implementation unit invoked directly rather than through further dependent packages.

Key Procedures and Functions

ETRM documents two procedures or functions for this package body. The documented entry is:

  • UPD — The primary update routine. As its name implies, it performs the maintenance of termination data, applying the changes determined by the higher-level termination business logic to the relevant payroll records. It is the sole documented callable entry point for this package and encapsulates the write side of termination processing, keeping the DML isolated from the validation and orchestration layers above it.

Because ETRM lists only the UPD procedure, callers should treat this package as an internal implementation detail of the termination framework rather than a general-purpose public API. No additional parameter signatures are documented; parameter lists should not be assumed and must be confirmed from the installed source in the target instance before any direct invocation.

Tables Accessed

The one table documented as referenced through APPS synonyms is PAY_TEMPLATE_EXCLUSION_RULES. This table stores the rules that determine which termination templates are excluded from selection for a given assignment or payroll context. PAY_TER_UPD reads this table so that the update routine can honour template-exclusion configuration when processing termination changes, ensuring that only permitted termination templates drive the resulting records.

Beyond this documented table, the package body's dependency list shows it calls into HR_API, HR_UTILITY, PAY_TER_BUS, and PAY_TER_SHD. These dependencies confirm that the package leans on the HR API layer for date-tracked datetrack writes, on HR utility routines for shared low-level operations, and on the sister termination packages for validation and shadow-record handling. Database writes themselves are therefore mediated through HRMS datetrack APIs rather than issued as raw DML.

Usage Notes

PAY_TER_UPD is not a user-facing API. It is invoked indirectly when an end user or process commits a termination through the Oracle HRMS termination form, through the Termination business process, or through any programmatic path that routes termination changes via PAY_TER_BUS. In a typical flow, the form or business layer validates the request, prepares the shadow records, and then delegates the actual persistence step to this package's UPD routine.

Because the package sits beneath the public termination API, customisations should not call PAY_TER_UPD directly. Supported integration points for terminations are the HR termination APIs and business process interfaces, which in turn invoke this package. Direct calls risk bypassing datetrack validation, template-exclusion checks, and payroll retroprocessing triggers, and would likely be broken by patch application. When diagnosing termination update behaviour in 12.1.1 or 12.2.2, this package is best examined as a debugging aid — for example, while tracing why a particular template-exclusion rule did or did not take effect — rather than as an extension target.