Search Results get_source_text_context

Overview

PAY_GB_RULES is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema, supplied as part of the Oracle Payroll localization for the United Kingdom (GB). The package encapsulates jurisdiction-specific payroll processing logic — its name follows the standard Oracle naming convention in which the PAY prefix denotes Oracle Payroll and the GB segment denotes the United Kingdom localization, while RULES indicates that the unit holds rule-based derivation logic used during payroll processing. In ETRM the package is classified as API classification OTHER, meaning it is an internal, implementation-support package rather than a formally published public API with guaranteed upward compatibility. The header stamp pygbrule.pkb 120.0 confirms the source file has been shipped at this form across the 12.1.1 and 12.2.2 release lines. Consistent with its role as a localization utility, the package is deliberately compact: it exposes a single documented procedure and performs no direct SQL against application tables.

Key Procedures and Functions

The ETRM metadata records exactly one documented program unit within the package body:

• GET_SOURCE_TEXT_CONTEXT — A procedure that supplies a defaulting value for a source-text context used in United Kingdom Court Order processing. In Oracle Payroll GB, Court Orders (for example, Deduction from Earnings Orders and Attachment of Earnings Orders) are processed as third-party payment rules that may reference a free-format "source text" element. This procedure is the hook that determines what text context should be presented or defaulted for that element. The implementation is intentionally minimal: it sets an initial literal value of 'Unknown' on the out parameter and writes progress markers through HR_UTILITY.SET_LOCATION at steps 1, 3, and 4, including a marker that echoes the derived value. No further branching, lookup, or calculation is performed in the shipped version. The NOCOPY hint on the output parameter is significant in a payroll batch context, since it avoids the copy-back overhead when the parameter is passed by reference during high-volume payroll runs. Because the body is stripped of either custom or customer-specific logic in the vanilla release, it functions as an extensible stub: a placeholder that implementers can override or wrap to supply their own Court Order context text.

Tables Accessed

The ETRM metadata lists no referenced tables for this package, either directly or through APPS synonyms. The package performs no DML and no SELECT statements; it neither reads from nor writes to any Oracle Payroll or Oracle HRMS base table. Its only external dependency is the Oracle HRMS utility package HR_UTILITY, invoked solely for trace and diagnostic output. Consequently, the procedure operates purely in PL/SQL memory on the parameter values passed to it. The absence of table access is consistent with the documented note that the package is referenced by zero other packages, indicating that it is invoked only from the payroll rules framework rather than forming part of a shared internal call graph.

Usage Notes

GET_SOURCE_TEXT_CONTEXT is an internal localization routine rather than an end-user-facing API. It is typically invoked by the Oracle Payroll GB rules engine during the processing of Court Order elements and by the relevant payroll setup forms when the source-text context must be defaulted for a Court Order definition. Because the packaged body simply returns 'Unknown', deployments that require meaningful Court Order source text must supply their own logic — normally through a custom wrapper or a localization-specific version of the package body — and should treat the APPS copy as a template rather than a functional implementation. Developers and support analysts who encounter this package while tracing a Court Order issue should note that the HR_UTILITY.SET_LOCATION calls are the primary diagnostic aid; they appear in FND_LOG and PL/SQL trace output and identify the procedure and step at which the default was set. Any such trace must be enabled by setting the relevant HR_UTILITY logging profile options, since the package emits no other instrumentation and produces no database activity that would appear in SQL trace. Given the OTHER API classification, the procedure signature must not be assumed to be stable across patches, and any custom dependency on it should be validated against the specific release and patch level in use.