Search Results chk_basis_assignment

Overview

HR_PAY_BASIS is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that encapsulates the business logic required to maintain pay basis definitions stored in the PER_PAY_BASES and PER_PAY_BASES_S tables. A pay basis links an input value to a rate in order to define how an element's pay value is calculated — for example, a flat amount, a percentage of a rate, or a rate multiplied by a factor. The package declares procedures to insert, update, and delete these pay bases while enforcing the validation rules that guarantee referential and uniqueness integrity across element, input value, and rate definitions. It is declared with AUTHID CURRENT_USER, so it executes with the privileges of the calling user, a standard convention for Oracle Forms–based APIs in the HR and Payroll modules. The header was originally created in November 1993 and last revised at version 115.2 (December 2002), reflecting its long-standing role in the Oracle Payroll data model.

Key Procedures and Functions

The package exposes ten documented program units:

• GENERATE_UNIQUE_ID — Returns a new unique identifier, typically used to populate the primary key of a pay basis row before insertion.
• INSERT_ROW — Inserts a new pay basis record, accepting the business group, name, pay basis type, input value, rate, and rate basis, and returning the generated pay basis identifier.
• CHK_NAME_UNIQUENESS — Verifies that the pay basis name is unique within the business group, optionally excluding the row currently being edited.
• CHK_INPUT_VAL_RATE_UK — Enforces the unique combination of input value and rate for a pay basis, accounting for template elements that span business groups.
• CHK_DUPLICATE_ELEMENT — Returns a Boolean indicating whether a duplicate element already exists for the given element type within the business group.
• CHK_ELEMENT_ENTRY — Validates that the supplied input value is properly associated with an element entry, guarding against invalid or orphaned input value references. This is the procedure most commonly associated with the search term "chk_element_entry."
• CHK_BASIS_ASSIGNMENT — Checks the assignment-level relationship between a pay basis and its assignments to prevent invalid associations.
• RETREIVE_FIELDS — Retrieves the descriptive fields associated with a pay basis record for display or downstream processing.
• VALIDATE_INSERT — Performs the full set of validations required before a new pay basis may be inserted.
• VALIDATE_UPDATE — Performs the equivalent validations when an existing pay basis is modified.

Tables Accessed

The package reads and writes the core payroll and HR tables through APPS synonyms. PER_PAY_BASES and its multilingual companion PER_PAY_BASES_S store the pay basis definitions themselves. PAY_INPUT_VALUES_F and PAY_INPUT_VALUES_F_TL supply input value definitions, while PAY_ELEMENT_TYPES_F and PAY_ELEMENT_TYPES_F_TL provide element type information used during duplicate detection. PAY_RATES holds the rate definitions referenced by a pay basis. PAY_ELEMENT_ENTRY_VALUES_F is consulted to confirm that an input value is actually used by an element entry, which underpins CHK_ELEMENT_ENTRY. PER_ALL_ASSIGNMENTS_F supports assignment-level validation performed by CHK_BASIS_ASSIGNMENT.

Usage Notes

HR_PAY_BASIS is not a public, standalone API and is not referenced by any other documented package. Its procedures are most commonly invoked from the Oracle Forms–based Pay Basis setup window within the Payroll responsibility, where they drive validation on save and record creation. Custom integrations that need to create or validate pay bases programmatically can call INSERT_ROW together with the CHK_ and VALIDATE_ procedures, but should always honor the business group context and the uniqueness rules enforced by CHK_NAME_UNIQUENESS and CHK_INPUT_VAL_RATE_UK. Because the package uses AUTHID CURRENT_USER, callers must have direct privileges on the underlying PER_ and PAY_ tables. As with all ETRM-classified "OTHER" packages, Oracle does not guarantee backward-compatible signatures across releases, so custom code should be regression-tested before upgrades from 12.1.1 to 12.2.2.