Search Results populate_context_items

Overview

APPS.PAY_PAYWIEEH_PKG is a server-side PL/SQL package in the Oracle E-Business Suite Payroll (PAY) module. Its documented purpose is to supply the data required by the Element Entry History form (PAYWIEEH), the Oracle Forms screen that presents the historical values of an employee's element entries across effective dates. The package is declared with AUTHID CURRENT_USER, meaning its unqualified database references resolve under the privileges of the invoking session rather than the package owner, a convention common to Oracle Forms-backed PL/SQL libraries in EBS.

The header comment records the package as created on 25 October 1994 by N. Simpson, with a header revision string referencing paywieeh.pkh version 115.0 dated 17 July 1999. This lineage confirms that the package is a long-standing component of the Payroll forms infrastructure rather than a later bolt-on. In ETRM 12.2.2 the package is classified as API classification OTHER, indicating that it is not a public, supported business API but an internal support package bound to a specific form. It is owned by APPS and, per the registered metadata, is referenced by zero other packages, reinforcing its status as a form-facing utility rather than a shared library.

Key Procedures and Functions

Two procedures are documented for this package.

• GET_ENTRY_VALUE_DETAILS — Returns the element entry values for each element entry selected by a query in the Element Entry History form. It accepts an element entry identifier, an element link identifier, and an effective date as its driving inputs, and populates a fixed set of screen-oriented output parameters. As declared in the package specification, these outputs follow a repeating pattern of fifteen name, fifteen unit-of-measure, and fifteen screen entry value parameters, allowing the form to display the multi-column entry value grid associated with the selected element entry as of the requested effective date.
• POPULATE_CONTEXT_ITEMS — Supplies the context item values required by the form. This corresponds directly to the user search term "populate_context_items." In Oracle Forms, context items carry key identifiers between blocks and are referenced by item-level triggers and LOVs; a procedure of this name is normally invoked during form navigation or query execution to seed those items from the currently selected record so that dependent blocks and validation logic resolve correctly.

Tables Accessed

The package reads the following tables through APPS synonyms, all of which are core Payroll element entry structures.

• PAY_ELEMENT_ENTRY_VALUES_F — the element entry values fact table holding the entered value for each input value on an element entry; this is the principal source of the historical entry values returned by GET_ENTRY_VALUE_DETAILS.
• PAY_INPUT_VALUES_F — defines the input values (entry value names, data types, and units of measure) belonging to an element, used to label and format each returned value.
• PAY_INPUT_VALUES_F_TL — the translation table providing the language-specific display names for those input values.
• PAY_LINK_INPUT_VALUES_F — links input values to element links, resolving the element link identifier passed into GET_ENTRY_VALUE_DETAILS and constraining the values that appear for a given link.

Usage Notes

The package is invoked from the PAYWIEEH form rather than from concurrent programs or public APIs. GET_ENTRY_VALUE_DETAILS is called when the form needs to render entry values for a selected element entry at a given effective date, and POPULATE_CONTEXT_ITEMS is called to set the form's context items so that subsequent queries and validations are correctly scoped. Because the package is not a supported public interface and is bound to a specific form's calling conventions — including its large fixed parameter list — custom code should not call it directly; the supported route for element entry value data is the public Payroll element entry APIs. Its inclusion in the APPS schema means it is captured in standard schema comparisons and patching, so any local modification would be overwritten during upgrade or patch application.