Search Results pay_ptt_upd




Overview
Explore in AI Chat

Overview

PAY_PTT_UPD is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as an "OTHER" API within the Oracle Payroll module. Its name derives from the object it manages — the PAY_USER_TABLES_TL entity — where "PTT" denotes user-defined Payroll Translation Tables and "TL" refers to the translation-language layer of that entity. In Oracle HRMS and Payroll, user tables provide a configurable mechanism through which implementers define their own lookup-style sets of values that can be referenced by payroll processing, element definitions, and related business rules. The PAY_USER_TABLES_TL table holds the translatable descriptive text associated with each user table and its rows.

The package therefore serves as the translation-maintenance utility for user tables, isolating the DML logic required to update the translated name and description columns of PAY_USER_TABLES_TL. By centralising this logic in a single API package, Oracle ensures that language-specific updates are performed consistently, that the WHO columns and row-level audit information are maintained correctly, and that any dependent objects are not left in an inconsistent state.

Key Procedures and Functions

The documented API surface of PAY_PTT_UPD consists of a single procedure:

  • UPD_TL — The sole documented entry point. Its purpose is to update the translation (TL) records associated with payroll user tables, applying the supplied translated text to the appropriate row in PAY_USER_TABLES_TL for the current session language. As is typical of Oracle TL-layer APIs, it is designed to be called once per language context rather than to manage the base (non-translated) table, which would be handled by a companion API such as PAY_USER_TABLE_API.

No parameter list is documented in the ETRM metadata, and parameter details should be confirmed against the package specification in the target environment before use.

Tables Accessed

The package references a single documented table through its APPS synonym:

  • PAY_USER_TABLES_TL — The translation table for payroll user tables. PAY_PTT_UPD reads and writes this table to store language-specific names and descriptions. Because the TL table is keyed by USER_TABLE_NAME (or an equivalent surrogate) combined with LANGUAGE and SOURCE_LANG, the procedure must respect the language of the calling session and the source language of the base record to preserve translation integrity. DML against this table is governed by the standard Oracle Payroll TL validation rules, including checks that the parent user table exists and that the language being updated is a valid installed language.

Dependency metadata also shows PAY_PTT_UPD referencing HR_API, Oracle's shared Human Resources API error-handling and message utility. This indicates that UPD_TL raises its errors through the standard HR_API mechanism, returning a structured error table rather than relying solely on PL/SQL exceptions — a hallmark of Oracle HRMS public APIs.

Usage Notes

PAY_PTT_UPD is referenced by three other packages — PAY_PTT_UPD (the body/spec reference recorded by ETRM), PAY_PUT_MNT_TL_ARU, PAY_USER_TABLES_PKG, and PAY_USER_TABLE_API — confirming its position as a low-level helper invoked indirectly by higher-level user-table maintenance APIs rather than called directly by end users. The naming of PAY_PUT_MNT_TL_ARU (User Table Maintenance – Translation – Application Reference Utility) strongly suggests that PAY_PTT_UPD is reached when a user-table maintenance form or ARU processes translation rows.

Typical invocation paths are the Oracle Payroll user-table maintenance windows in the HRMS forms, or the seeded user-table maintenance concurrent programs, both of which ultimately delegate TL updates to this package. Direct calls from custom code are possible but discouraged; customers requiring user-table translation changes should use the public API layer (PAY_USER_TABLE_API and its ARU), which in turn calls PAY_PTT_UPD. Because the package writes only to the TL layer, it is safe with respect to base-table data but must be invoked within the correct NLS language context. The status of the object is VALID in both 12.1.1 and 12.2.2, and no significant behavioural differences are documented between these releases.