Results for “element_set_type_meaning”

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

Overview

PAY_ELEMENT_SETS_V is a validation view owned by the APPS schema in Oracle E-Business Suite, defined in the Payroll (PAY) product module. In both EBS 12.1.1 and 12.2.2, the object is documented as VALID and is described in ETRM simply as "Used to support user interface." This places the view squarely in the class of UI-support (LOV and form-query) database objects that Oracle Payroll forms and self-service pages use to present element set information to end users, rather than in the class of transactional or interfacing entities.

Its principal role is to expose the element set definition table together with the decoded lookup meaning of the element set type, so that a form or concurrent program can display a readable value ("Element Set Type Meaning") instead of an opaque lookup code. Because it carries the ROWID of the underlying element set row, the view is also usable as a form-level query source that supports update of the base record through the key-preserved ROWID. It is not a reporting-only construct, but because its column list mirrors the base table closely and adds a decoded attribute, it is frequently reached for in ad hoc reporting and in integration extracts where a human-readable element set type is required without an additional join to HR_LOOKUPS.

Underlying Base Objects

The ETRM metadata for 12.2.2 documents three referenced base objects: HR_API (PACKAGE), HR_LOOKUPS (VIEW), and PAY_ELEMENT_SETS (SYNONYM). The view text confirms the two relations actually joined in the SELECT statement:

• PAY_ELEMENT_SETS ELS — the driving table (referenced through the public synonym). It supplies the element set identifier, business group, legislation, name, type code, comments, and WHO audit columns.
• HR_LOOKUPS HL — joined on HL.LOOKUP_TYPE = 'ELEMENT_SET_TYPE' and HL.LOOKUP_CODE = ELS.ELEMENT_SET_TYPE, supplying the MEANING column exposed as ELEMENT_SET_TYPE_MEANING.

HR_API is documented as a referenced package, reflecting the standard Oracle Payroll pattern in which the base table's DML—and the validation that guards it—is encapsulated in the HR_API business logic layer; the view itself is a projection over the persisted data rather than a computation. The join is a lookup decode, so the view returns one row per element set, provided a matching ELEMENT_SET_TYPE lookup code exists. The arithmetic expression ELS.BUSINESS_GROUP_ID + 0 is a standard Oracle Forms device that forces the business group column to be treated as a non-key, queryable attribute in the block.

Key Columns

• ROW_ID — the ROWID of the PAY_ELEMENT_SETS row; supports identifying and updating the underlying record.
• ELEMENT_SET_ID — system-generated primary key of the element set.
• BUSINESS_GROUP_ID — the business group that owns the element set; the principal security/partitioning attribute.
• LEGISLATION_CODE — the legislation under which the element set is valid.
• ELEMENT_SET_NAME — the user-defined name of the element set.
• ELEMENT_SET_TYPE — the lookup code classifying the element set.
• COMMENTS — free-text description entered by the user.
• ELEMENT_SET_TYPE_MEANING — the decoded lookup meaning for ELEMENT_SET_TYPE from HR_LOOKUPS.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.

Common Use Cases and Queries

Typical uses include LOV population for element set selection, display of element sets by business group and legislation, and extract queries where the decoded type is required. A representative query is:

• SELECT element_set_id, element_set_name, element_set_type_meaning, legislation_code FROM pay_element_sets_v WHERE business_group_id = :p_business_group_id ORDER BY element_set_name;
• SELECT element_set_name FROM pay_element_sets_v WHERE element_set_type = :p_type AND legislation_code = :p_legislation;
• SELECT element_set_id, row_id FROM pay_element_sets_v WHERE element_set_name = :p_name; for form-level navigation or update.

Because the join to HR_LOOKUPS requires a matching lookup code, absent or inactive lookup rows can suppress results; queries should therefore not rely on the view alone when completeness of element sets is required.