Search Results per_pay_bases_s

Overview

HR_PAY_BASIS is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema that encapsulates the server-side business logic governing pay basis definitions in Oracle Payroll and Oracle Human Resources. Pay bases define the rate or amount foundations on which element input values, pay rates, and assignment-level compensation are calculated—for example, hourly, salaried, or period-based rates. The package functions as the programmatic backbone behind the Pay Basis configuration and validation layer, exposing procedures that create, validate, and maintain rows referenced by payroll processing and element entry. Although classified as an OTHER API rather than a formally published public API, its procedures are callable and are typically driven by the associated maintenance forms and validation routines rather than by third-party integrations.

Key Procedures and Functions

The TRM metadata documents ten procedures and functions within this package body. Their purposes are as follows:

• GENERATE_UNIQUE_ID — Produces a system-generated unique identifier for a new pay basis row, ensuring primary key integrity on insert.
• INSERT_ROW — Inserts a new pay basis record into the underlying base table, populating the mandatory columns and audit attributes.
• CHK_NAME_UNIQUENESS — Validates that the pay basis name supplied does not duplicate an existing entry.
• CHK_INPUT_VAL_RATE_UK — Enforces uniqueness and consistency of the combination of pay basis, input value, and rate definition.
• CHK_DUPLICATE_ELEMENT — Detects whether an element is already associated with the pay basis, preventing overlapping definitions.
• CHK_ELEMENT_ENTRY — Verifies element entry relationships tied to the pay basis before allowing creation or modification.
• CHK_BASIS_ASSIGNMENT — Checks whether the pay basis is already referenced by any assignment, which would restrict deletion or alteration.
• RETREIVE_FIELDS — Retrieves the descriptive and control attributes of a pay basis for downstream use (note the original spelling "RETREIVE").
• VALIDATE_INSERT — Aggregates the insert-time validation checks, calling the individual validation procedures before an insert is committed.
• VALIDATE_UPDATE — Aggregates the update-time validation checks, ensuring changes do not violate established business rules.

Tables Accessed

HR_PAY_BASIS reads and writes the following documented tables (through APPS synonyms):

• PER_PAY_BASES and PER_PAY_BASES_S — the base and translation tables holding pay basis definitions; these are the primary targets of INSERT_ROW and the validation queries.
• PAY_ELEMENT_TYPES_F, PAY_ELEMENT_TYPES_F_TL — element type definitions consulted for duplicate element and element entry validation.
• PAY_INPUT_VALUES_F, PAY_INPUT_VALUES_F_TL — input value definitions, used to enforce rate and input value uniqueness.
• PAY_ELEMENT_ENTRY_VALUES_F — element entry values checked when validating element entries.
• PAY_RATES — rate definitions joined to validate the pay basis to rate relationship.
• PER_ALL_ASSIGNMENTS_F — assignment records examined to determine whether a pay basis is in active use.
• HR_LOOKUPS and DUAL — lookup values for coded validation and single-row utility queries respectively.

Because the package both queries and inserts into PER_PAY_BASES, it acts as a data-maintenance gateway rather than a purely read-only utility.

Usage Notes

HR_PAY_BASIS is not referenced by any other database object, indicating it is invoked directly rather than through an inheritance chain. In practice it is called by the Pay Basis maintenance form (a Forms-based DML handler) and by any custom validation scripts that manipulate pay basis records. Because the package has no dependents, it should be treated as an internal implementation detail; direct custom calls should be limited to validation rather than bypassing the standard forms, since the validation procedures encode business rules regarding duplicate elements, assignment usage, and rate/input value uniqueness. The absence of a formal public API classification means Oracle does not guarantee signature stability across patches, so custom code should invoke only the documented procedures and be re-tested after upgrading from 12.1.1 to 12.2.2. All execution occurs in the APPS schema with standard APPS privileges and the package status is VALID.