Search Results get_g_current_entry_id




Overview

APPS.HR_CAL_ENTRY_VALUE_API is a PL/SQL application programming interface that manages the individual value records associated with calendar entries in Oracle EBS Human Resources. In the Oracle HRMS calendar architecture, a calendar entry (for example, a scheduled holiday, an organization-wide event, or a scope-specific date record) is stored in a parent table, while the discrete values that qualify that entry are held in child value records. HR_CAL_ENTRY_VALUE_API encapsulates the create, update, delete, and query logic for these child value records, shielding callers from the underlying table structures and enforcing the same validation and auditing rules used throughout the HR API family.

The package is classified as an API object owned by the APPS schema and is VALID in the documented 12.2.2 environment. It depends on APPS.HR_API, the common HR error-handling and buffer-management package, and on the SYS.STANDARD package. It is referenced directly by HR_CALENDAR_ENTRY_API, HR_CAL_ENTRY_VALUE_SWI, and by itself, and it in turn is referenced by several calendar value views including PER_CAL_ENTRY_VALUES_V, PER_CAL_ORG_HIER_VALUES_V, and PER_CAL_SCOPE_VALUES_V. It is also referenced by five other packages, confirming its role as a shared service within the calendar feature set.

Key Procedures and Functions

The ETRM metadata documents eleven callable units. Their purposes are as follows.

  • CREATE_ENTRY_VALUE — inserts a new calendar entry value record, performing the standard HR API validation and returning the generated identifier to the caller.
  • UPDATE_ENTRY_VALUE — modifies attributes of an existing calendar entry value record.
  • DELETE_ENTRY_VALUE — removes a calendar entry value record, subject to the referential and validation rules imposed by the HR API layer.
  • GET_DISPLAY_VALUE — returns the display representation of a value, resolving the stored code to its user-facing form.
  • GET_G_CURRENT_ENTRY_ID / SET_G_CURRENT_ENTRY_ID — accessor pair for the package-level global that tracks the calendar entry currently being processed, allowing related values to be bound to a single entry context.
  • GET_G_CURRENT_OSV_ID / SET_G_CURRENT_OSV_ID — accessor pair for the global holding the current organization structure version identifier, which scopes value processing to a particular organizational context.
  • GET_NODE_LEVEL — returns the hierarchical level of a given node within the organization hierarchy.
  • GET_ELE_LEVEL — returns the level of an organization structure element, used when the value is scoped to an element rather than a node.
  • GET_SQL_FROM_VSET_ID — builds and returns the SQL fragment associated with a given flex value set, allowing dynamic validation of value-set-driven entries.

The presence of the get/set global accessors indicates that the API is designed for use within a controlled processing loop, where the current entry and organization version are established once and then reused across multiple value operations.

Tables Accessed

Through APPS synonyms, the package reads and writes the following base tables.

Usage Notes

HR_CAL_ENTRY_VALUE_API is an internal, server-side API rather than an end-user entry point. It is normally invoked indirectly: the HRMS calendar forms and the higher-level HR_CALENDAR_ENTRY_API call it when a user creates or amends calendar entries that carry associated values, and the SWI (Server Web Interface) layer, HR_CAL_ENTRY_VALUE_SWI, exposes its operations to web-based and self-service flows. The dependent views PER_CAL_ENTRY_VALUES_V, PER_CAL_ORG_HIER_VALUES_V, and PER_CAL_SCOPE_VALUES_V read the results of value processing for reporting and display.

Custom and extension code should call this package rather than performing direct DML against PER_CAL_ENTRY_VALUES, so that HR_API validation, error stacking, and audit behaviour are preserved. Callers should establish the current entry and organization structure version context using the SET_G_CURRENT_ENTRY_ID and SET_G_CURRENT_OSV_ID routines before issuing value-level operations, and should check the HR_API error stack after each call. Because the package is referenced by multiple components, any modification to its specification should be treated as a shared-interface change and regression-tested against the calendar forms, the SWI layer, and the dependent views.