Search Results get_template_info

Overview

APPS.PAY_SBF_BUS is a server-side PL/SQL package body belonging to the Oracle Payroll module of Oracle E-Business Suite. Its name reflects its role as the business logic layer for the Shadow Balance Feeds (SBF) entity, a configuration construct that determines how balances are fed into the payroll balance engine. The package encapsulates the validation and processing rules that govern the creation, maintenance, and removal of shadow balance feed records, shielding the underlying tables from direct manipulation by forms, concurrent programs, or custom code.

The package header declares it as a "B" (business) layer object within the standard Oracle EBS API architecture, complementing the shadow (SH) and table-handler (TH) layers. It is documented under API classification OTHER in the ETRM repository and is referenced by three other packages, indicating it participates in a dependency chain used by payroll setup and balance processing components. The package body header identifies the source file and version lineage (pysbfrhi.pkb), confirming it as a shipped Oracle object rather than a customer extension.

Key Procedures and Functions

The documented callable API surface consists of three validation procedures, all conforming to the EBS C-API convention of separating validation from the underlying DML performed by the table handler.

• INSERT_VALIDATE — Executed before a new shadow balance feed record is inserted. It performs the business rules and cross-entity consistency checks required to confirm the record is valid for creation.
• UPDATE_VALIDATE — Executed before an existing record is modified. It enforces the rules restricting what may be changed and validates that the updated state remains consistent with related payroll configuration.
• DELETE_VALIDATE — Executed before an existing record is removed. It determines whether deletion is permissible given dependent configuration.

In addition to these documented procedures, the package body contains the private procedure get_template_info, which corresponds directly to the user's search term. This procedure accepts an input value identifier and resolves the associated element template identifier by querying the shadow input values, shadow element types, and element templates tables in a single joined cursor. It returns the template identifier through an IN OUT NOCOPY parameter. Because it is a private routine, it is not part of the published API and is invoked only from within PAY_SBF_BUS. A further internal routine, chk_non_updateable_args, guards against updates when a core balance classification has already been generated from the shadow balance classification, protecting downstream payroll calculations from invalid reconfiguration.

Tables Accessed

PAY_SBF_BUS operates against seven documented tables, accessed through APPS synonyms.

• PAY_SHADOW_BALANCE_FEEDS — The primary entity maintained by the package; holds the feed definitions linking shadow balances to their consuming balances.
• PAY_SHADOW_BALANCE_TYPES — Defines the shadow balance classifications referenced by feed records and used in validation checks.
• PAY_SHADOW_INPUT_VALUES — Stores shadow input values; read by get_template_info to resolve the owning element type.
• PAY_SHADOW_ELEMENT_TYPES — Links shadow element types to element templates; joined in get_template_info.
• PAY_ELEMENT_TEMPLATES — Supplies the template identifier ultimately returned by get_template_info.
• PAY_TEMPLATE_CORE_OBJECTS — Records core objects generated from templates; used in validation logic.
• PAY_TEMPLATE_EXCLUSION_RULES — Captures exclusion rules that constrain which core objects may be generated, supporting validation and non-updateable argument checks.

Usage Notes

PAY_SBF_BUS is not intended for direct invocation by end users or ad hoc scripts. It is normally called by the Oracle Payroll setup forms and by the standard table-handler layer whenever shadow balance feed records are created, changed, or deleted. Because the validation procedures enforce referential and state rules across the shadow balance and template tables, direct DML against the underlying tables bypasses these safeguards and can produce inconsistent payroll configuration. Custom code should invoke the published validation routines only in the sequence prescribed by the EBS API pattern — validate first, then delegate the DML to the corresponding table handler. Since the package is referenced by three other packages, modifications to its behavior can propagate through dependent payroll processing; integrators should treat it as a protected, Oracle-owned object and avoid recompiling or extending it outside supported extension mechanisms.