Search Results custom_pay_calc

Overview

The PL/SQL package body APPS.GHR_CUSTOM_PAY_CALC is a customer-facing extension point within the Oracle E-Business Suite (EBS) Human Resources and payroll calculation framework. It is owned by the APPS schema and classified under the ETRM API category OTHER. The package exists to provide implementers with a hook into the standard Oracle payroll processing engine, allowing organization-specific compensation rules to be applied when the seeded Oracle payroll calculation logic cannot meet a particular legislative, contractual, or business requirement.

The package's header comment, dated 99/10/18 with the version tag ghcustpc.pkb 115.1, confirms its origins in the early HRMS codebase that persists largely unchanged into EBS 12.1.1 and 12.2.2. Its body is intentionally minimal: it declares a single global package name variable (g_package) and a single procedure, custom_pay_calc, whose body consists of a placeholder comment instructing the developer to "Add custom code here," followed by a fully commented-out example.

Functionally, the package serves as the sanctioned seam between Oracle's standard pay calculation flow and customer-defined logic. Oracle retains ownership of the shipped package, and customers are expected to copy or extend the example logic into a local customization rather than modifying the delivered source directly.

Key Procedures and Functions

• CUSTOM_PAY_CALC — The single documented procedure in the package. It represents a customizable callback invoked by the standard payroll calculation engine. The procedure is designed to receive the current pay data record, return an output record containing calculated pay elements, and signal via boolean flags whether the calculation was performed (p_calculated) and whether an error message was set (p_message_set). The body shipped by Oracle contains no active logic: it logs entry via hr_utility.set_location and then executes only the commented example. Implementers are expected to insert their own pay calculation rules here, following the pattern of the example, which sets output fields such as basic_pay, locality_adj, adj_basic_pay, total_salary, and related pay components for a given pay basis.

The example illustrates the intended contract: the procedure should verify that the calculation has not already been performed, branch on p_pay_data_rec.pay_basis, populate all output parameters, and set p_calculated to TRUE and p_message_set to FALSE to indicate successful completion.

Tables Accessed

The ETRM metadata records no tables referenced through APPS synonyms for this package. This is consistent with the shipped body, which contains no SQL statements, cursors, or DML operations. All data required by the procedure is passed in and out through the strongly typed record parameters defined in ghr_pay_calc.pay_calc_in_rec_type and ghr_pay_calc.pay_calc_out_rec_type. Any table access introduced by a customer implementation would be performed against customer-selected tables via their own code, and would not be recorded as part of the delivered package's documented footprint.

Usage Notes

APPS.GHR_CUSTOM_PAY_CALC is not invoked directly by end users or standard concurrent programs. It is called from within the Oracle payroll calculation flow, which supplies the pay input record and consumes the output record produced by the custom procedure. Typical invocation therefore occurs during payroll runs or pay calculation diagnostics that exercise the GHR pay calculation path.

Metadata indicates the package is referenced by one other package, which is expected to be the standard calculation driver that calls the custom hook when a pay basis requires customer logic. Because the delivered body is a stub, all behavior depends on the customer's own implementation. Implementers should:

• Copy the delivered package into a custom schema or extension package rather than editing the shipped source, preserving upgrade safety across 12.1.1 and 12.2.2.
• Ensure every output parameter is assigned before setting p_calculated := TRUE, as partial population can produce incorrect payroll results.
• Use p_message_set and hr_utility message routines to surface errors to the calculation engine.
• Validate all custom logic in a test environment before it is exercised by live payroll processing.