Results for “hr_summary_key_values_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

HR_SUMMARY_KEY_VALUES_V is a documented Oracle E-Business Suite view owned by the APPS schema and registered as a VALID object under the PER (Human Resources) product family. It is a denormalized read-only view that consolidates rows from two underlying summary-key views — HR_SUMMARY_KEY_VALUE and HR_SUMMARY_KEY_TYPE — joining each key value to its parent key type. The view exists to provide a single, flattened source for the key types and their associated values used throughout the HR summary framework, which drives configurable list-of-values, flexfield-style lookup behavior, and other HR configuration surfaces.

In the context of EBS 12.1.1 and 12.2.2, this view supports reporting, data extraction, and integration scenarios where consumers need to resolve a stored item value ID back to its human-readable key type and key value names. Because it resides in the APPS schema and applies the standard business-group security filter, it is typically referenced by concurrent programs, BI Publisher reports, and custom extensions rather than by direct end-user navigation.

Underlying Base Objects

The ETRM metadata documents the view text as a two-object join:

• HR_SUMMARY_KEY_VALUE (KV) — supplies the NAME column projected as KEY_VALUE, the foreign key KEY_TYPE_ID, and the surrogate ITEM_VALUE_ID.
• HR_SUMMARY_KEY_TYPE (KT) — supplies the NAME column projected as KEY_TYPE, keyed on KEY_TYPE_ID.
• HR_GENERAL (PACKAGE) — invoked through HR_GENERAL.GET_BUSINESS_GROUP_ID, which supplies the current session business group used in the NVL predicate so that rows are restricted to the caller's business group unless KV.BUSINESS_GROUP_ID is NULL.
• HR_API (PACKAGE) — documented as a referenced base object, supporting the HR security and API infrastructure surrounding these summary-key entities.

Both HR_SUMMARY_KEY_VALUE and HR_SUMMARY_KEY_TYPE are themselves exposed as views rather than base tables, meaning HR_SUMMARY_KEY_VALUES_V sits one layer above the underlying summary-key storage. The join predicate is KV.KEY_TYPE_ID = KT.KEY_TYPE_ID, combined with the business-group restriction, producing a business-group-scoped, key-type-grouped result set.

Key Columns

The view exposes exactly three columns, as documented in ETRM:

• KEY_VALUE — the NAME value originating from HR_SUMMARY_KEY_VALUE (KV.NAME). This is the descriptive value associated with a given summary key entry.
• KEY_TYPE — the NAME value originating from HR_SUMMARY_KEY_TYPE (KT.NAME). This identifies the category or type that the key value belongs to, derived via the KEY_TYPE_ID join.
• ITEM_VALUE_ID — the surrogate identifier (KV.ITEM_VALUE_ID) for the underlying key value row. This is the stable technical reference used by dependent data, and it is the column most useful for joining back to transactional or configuration tables when a foreign key was captured instead of a display value.

Notably, KEY_TYPE_ID and BUSINESS_GROUP_ID are consumed internally by the join and filter but are not projected, which keeps the interface intentionally narrow.

Common Use Cases and Queries

Typical usage centers on translating IDs to display values, validating configured key types and values, and building downstream reports. A representative query selects all key values for a given key type:

• Resolve a key type's values: SELECT key_value, item_value_id FROM apps.hr_summary_key_values_v WHERE key_type = '&key_type' ORDER BY key_value;
• Look up a display value from a stored ID: SELECT key_type, key_value FROM apps.hr_summary_key_values_v WHERE item_value_id = :item_value_id;
• Enumerate configured key types: SELECT DISTINCT key_type FROM apps.hr_summary_key_values_v ORDER BY key_type;
• Integrate into a report dataset: join ITEM_VALUE_ID to transactional HR tables to present human-readable key values without hardcoding lookup logic.

Because business-group filtering is applied automatically via HR_GENERAL.GET_BUSINESS_GROUP_ID, queries run under a specific HR responsibility return only that group's rows; cross-business-group extraction requires running under a responsibility with the appropriate business group context or querying the underlying base views directly.