Search Results pay_user_table_api




Overview
Explore in AI Chat

Overview

PAY_USER_TABLE_API is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite, classified as an API in the ETRM repository. Its business purpose is to manage the definition of user-defined tables within Oracle Payroll. User tables are the extensibility mechanism through which implementers define additional payroll-related data structures — such as pay and input value definitions, balance feeds, and lookup-style configurations — that are consumed by payroll processes, formulas, and element entries. The package encapsulates the create, update, and delete lifecycle of these user table definitions, ensuring that the underlying payroll data model remains consistent and that all mandatory columns, validation rules, and cross-references are populated correctly. It is therefore a core building block for payroll configuration rather than a transactional processing routine; it is invoked during setup and maintenance of payroll definitions, not during payroll runs. The package is marked VALID in both 12.1.1 and 12.2.2, and it is documented as having three public procedures.

Key Procedures and Functions

The ETRM metadata documents three procedures on PAY_USER_TABLE_API, each corresponding to a distinct DML operation on the user table definition:

  • CREATE_USER_TABLE — Creates a new user table definition. This is the entry point used when an implementer defines an entirely new payroll user table that does not yet exist in the system.
  • UPDATE_USER_TABLE — Modifies an existing user table definition. It is used to change attributes of a table that has already been created, such as descriptive metadata associated with the definition.
  • DELETE_USER_TABLE — Removes an existing user table definition. Because user tables can be referenced by other payroll objects, this procedure is the sanctioned path for teardown and should be preferred over direct DML.

The ETRM record does not enumerate formal parameter lists for these procedures; the reader should obtain the exact signatures from the package specification in the APPS schema. The package body depends on HR_API, reflecting the standard HR/Payroll API pattern in which the public API validates inputs and delegates the low-level work to an internal HR_API routine.

Tables Accessed

The ETRM excerpt for this object does not list the underlying tables referenced by PAY_USER_TABLE_API; the "Tables referenced (via APPS synonyms)" section is empty in the supplied metadata. Based on the Payroll data model, the package operates against the core user table definition tables within the PAY schema (for example, the PAY_USER_TABLES and PAY_USER_COLUMNS family), writing the header and column-level rows that constitute a user table definition. No direct table access should be assumed by consumers — all persistence is performed internally by the package, and callers are expected to interact only through the documented procedures. Where downstream objects such as PAY_USER_TABLE_DETAILS_PKG and HRDPP_CREATE_USER_TABLE reference this package, they rely on it to keep those definition tables synchronized.

Usage Notes

PAY_USER_TABLE_API is intended to be called from PL/SQL — typically from seeded concurrent programs, from the Payroll setup forms, or from custom configuration scripts — rather than executed interactively. The ETRM dependency data shows that it is referenced by two other packages, HRDPP_CREATE_USER_TABLE and PAY_USER_TABLE_DETAILS_PKG, indicating that it is itself a reusable building block invoked by higher-level setup routines. Custom code should call the three public procedures instead of inserting into or updating the underlying payroll tables directly, because the API enforces validation and the HR_API contract. Callers must supply a valid API context (such as an initialized HR_API business group and effective date) before invocation is attempted. Because the procedures mutate payroll setup definitions, they should be run with appropriate privileges and during controlled change windows, and the standard practice of testing in a cloned environment prior to production use applies.