Search Results ghr_element_entries_h_v




Overview
Explore in AI Chat

Overview

The GHR_ELEMENT_ENTRIES_H_V view is an APPS-owned, VALID database view within the GHR — US Federal Human Resources product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to provide a mapping of GHR_PA_HISTORY columns to the PAY_ELEMENT_ENTRIES_F structure. In effect, it presents the generic informational columns of the personnel action history table (INFORMATION1 through INFORMATIONn) re-cast, converted, and renamed as the named attributes of a payroll element entry, such as ELEMENT_ENTRY_ID, EFFECTIVE_START_DATE, ASSIGNMENT_ID, and ELEMENT_LINK_ID.

The view functions as a decoding and integration layer rather than as a stored base entity. It allows Oracle EBS reporting, concurrent processing, and integration components to interrogate GHR personnel action history records produced by element entry business events as though they were conventional payroll element entry rows, without requiring the calling program to understand the positional INFORMATION* encoding used by the history table. Because the underlying GHR_PA_HISTORY records are also used for audit, the view is read-oriented and should be treated as a query surface.

Underlying Base Objects

ETRM documents three referenced base objects for this view, all resolved through the APPS schema:

The view therefore depends on two supplied PL/SQL packages at parse/execution time, and its rows are a subset of GHR_PA_HISTORY rows corresponding to element entry changes.

Key Columns

  • PA_HISTORY_ID — the surrogate identifier of the underlying history record; the logical row key.
  • PROCESS_DATE / EFFECTIVE_DATE — processing timestamp and the business effective date of the captured change.
  • DML_OPERATION — indicates the operation type captured (for example insert, update, or delete).
  • PRE_VALUES_FLAG — identifies records holding pre-change image values.
  • PA_REQUEST_ID / ALTERED_PA_REQUEST_ID / NATURE_OF_ACTION_ID — linkage to the originating personnel action request and its nature of action.
  • ELEMENT_ENTRY_ID — decoded numeric element entry identifier; the principal business key for downstream lookups.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — date-converted element entry date ranges.
  • ASSIGNMENT_ID — the assignment to which the element entry applies.
  • ELEMENT_LINK_ID — the element eligibility link under which the entry was created.
  • COST_ALLOCATION_KEYFLEX_ID — reference to the costing flexfield allocation for the entry.
  • ORIGINAL_ENTRY_ID / TARGET_ENTRY_ID / UPDATING_ACTION_ID — cross-references to related or superseded entries and the action that modified them.
  • CREATOR_TYPE / CREATOR_ID / ENTRY_TYPE / REASON — truncated text attributes describing who or what created the entry, the entry type, and the reason.
  • COMMENT_ID / SUBPRIORITY / PERSONAL_PAYMENT_METHOD_ID / DATE_EARNED — supporting payroll attributes.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield context and segment values, substr-truncated to documented widths.

Common Use Cases and Queries

Typical usage revolves around auditing element entry activity, reconciling history to live payroll data, and reporting personnel action impact on pay. Because ELEMENT_ENTRY_ID is decoded from INFORMATION1, it can be joined to live element entry and assignment data.

  • Audit trail of changes to a specific element entry over time.
  • Reporting element entry activity by assignment, element link, or nature of action.
  • Extracting pre-change and post-change images using PRE_VALUES_FLAG.
  • Feeding downstream integrations that expect element entry-shaped rows without reading the raw history encoding.

Sample query:

SELECT v.pa_history_id,
       v.process_date,
       v.dml_operation,
       v.element_entry_id,
       v.assignment_id,
       v.element_link_id,
       v.effective_start_date,
       v.effective_end_date,
       v.creator_type,
       v.entry_type
  FROM apps.ghr_element_entries_h_v v
 WHERE v.assignment_id = :p_assignment_id
   AND v.process_date >= :p_from_date
 ORDER BY v.process_date, v.pa_history_id;

Filters should generally be applied on decoded columns rather than on raw INFORMATION* columns, since the decoding work is performed inside the view and is not indexable on the encoded source.