Search Results hr_h2pi_element_entry_values




Overview
Explore in AI Chat

Overview

The HR.HR_H2PI_ELEMENT_ENTRY_VALUES table is a Human Resources (PER) module object within Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the individual input values captured against element entries in the Oracle Payroll and Human Resources element entry framework, forming part of the H2PI (an internal naming convention associated with the element entry processing architecture) family of tables. As a VALID object owned by the HR schema, it participates in the date-effective, business-group-partitioned model that underpins Oracle Payroll processing and compensation data capture.

The documented physical schema lists 10 columns. The heuristic Data Vault classification supplied in the metadata is standalone, indicating that the table is not modelled as a hub, link, or satellite but rather as an independent structure with no mined foreign-key relationships. Where a Data Vault interpretation is desired, the effective-dated structure and multi-part primary key suggestions a satellite-like treatment keyed on the element entry and its effective period; however, the absence of mined FK edges means this is a modelling suggestion rather than a documented dependency.

Key Information Stored

The table's primary key is HR_H2PI_ELEMENT_ENT_VALUES_PK, composed of ELEMENT_ENTRY_ID, EFFECTIVE_START_DATE, EFFECTIVE_END_DATE, BUSINESS_GROUP_ID, and CLIENT_ID. This composite key establishes the date-effective, multi-tenant nature of the records. The most significant columns include:

  • ELEMENT_ENTRY_ID — Identifies the parent element entry to which the captured input value belongs; a surrogate-style identifier linking the value to its entry context.
  • INPUT_VALUE_ID — Identifies the specific input value definition being populated, defining which element input this value satisfies.
  • PERSON_ID — Associates the entry value with the person (assignment holder) for whom the element entry was created.
  • SCREEN_ENTRY_VALUE — Holds the actual value entered by the user at the screen or interface layer, typically as a character representation subject to later validation or conversion.
  • STATUS — Indicates the processing or validation state of the entry value record.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — Define the date-effective window during which the record is valid, supporting Oracle's standard date-tracked data model.
  • BUSINESS_GROUP_ID — Partitions data by enterprise business group, enforcing multi-tenant separation.
  • CLIENT_ID — Supports multi-tenant or client-level discrimination, forming part of the primary key.
  • LAST_UPD_DATE — Audit column recording the most recent update timestamp.

The primary key constitutes the surrogate composite identifier; the combination of ELEMENT_ENTRY_ID, INPUT_VALUE_ID, and the effective dates serves as the principal business-key candidate for uniquely identifying an input value instance.

Common Use Cases and Queries

Typical use cases centre on payroll input verification, element entry auditing, and date-effective value reporting. A common query pattern retrieves all input values for a given element entry as of a specific date:

  • Reporting current input values: SELECT element_entry_id, input_value_id, screen_entry_value, status FROM hr.hr_h2pi_element_entry_values WHERE element_entry_id = :p_entry_id AND TRUNC(SYSDATE) BETWEEN effective_start_date AND effective_end_date;
  • Auditing historical changes by selecting rows ordered by effective_start_date to trace how an input value evolved.
  • Reconciling screen-entered values against processed payroll results, joining on ELEMENT_ENTRY_ID and PERSON_ID.
  • Data migration or interface validation, checking that SCREEN_ENTRY_VALUE and STATUS conform before downstream processing.

Because the table is documented as standalone, queries should not assume implicit foreign-key joins; explicit join conditions on ELEMENT_ENTRY_ID and INPUT_VALUE_ID are required.

Related Objects

Based on the documented architecture and the element entry framework, the most significant related objects include:

As the metadata records no mined foreign-key edges, these relationships should be validated against the actual database constraints before being relied upon in production reporting.