Search Results processing_order




Overview
Explore in AI Chat

Overview

HXTFV_ADD_ELEM_INFO is an APPS-owned read-only view in the Oracle E-Business Suite Time and Labor (HXT) module. Its purpose is to expose the definition of Time and Labor additional element information to reporting, forms, and integration consumers in a decoded, human-readable form. The view is defined over the HXT_ADD_ELEM_INFO_F table, with joins to PAY_ELEMENT_TYPES_F, and uses Oracle HRMS lookup decoding to translate internal codes into descriptive values.

The view is a crucial component of the Time and Labor element configuration model, since it presents earning category, absence type, premium type, premium amount, processing order, and expenditure type for each element type that has additional element information defined. This is a security and abstraction layer: forms and concurrent programs query the view rather than the underlying table, and the view is published as WITH READ ONLY to prevent unintended data modification.

Underlying Base Objects

The ETRM 12.2.2 metadata for this object lists three referenced base objects:

  • HXT_ADD_ELEM_INFO_F (SYNONYM) — the primary source table, containing additional element information records, including earning category, absence type, premium type, premium amount, processing order, expenditure type, and attribute category. The view aliases this table as EIF.
  • PAY_ELEMENT_TYPES_F (SYNONYM) — the Payroll element type definitions, providing element name (ELEMENT_NAME) and element type identifier (ELEMENT_TYPE_ID). The view aliases this table as PET.
  • HR_GENERAL (PACKAGE) — supplies the DECODE_LOOKUP function used to translate coded values for earning category, absence type, and premium type into descriptive lookup meanings.

The view filters both the HXT_ADD_ELEM_INFO_F and PAY_ELEMENT_TYPES_F records to the effective date range that contains the current SYSDATE, and joins them on ELEMENT_TYPE_ID, ensuring only currently effective element configuration is presented.

Key Columns

  • EARNING_CATEGORY — Decoded description of the earning category from the HXT_EARNING_CATEGORY lookup, indicating how the additional element information is categorized for earnings processing.
  • ABSENCE_TYPE and ABSENCE_POINTS — The decoded absence type from the HXT_ABSENCE_TYPE lookup, plus the absence points associated with the element.
  • PREMIUM_TYPE and PREMIUM_AMOUNT — Decoded premium type from the HXT_PREMIUM_TYPE lookup, with the corresponding premium amount used in premium calculation processing.
  • PROCESSING_ORDER — The numeric order in which the additional element information is applied during Time and Labor processing. This column is the focus of the searched term and controls the sequence of evaluation among competing or dependent element rules.
  • EXPENDITURE_TYPE — Expenditure type associated with the element, often used in costing and project accounting contexts.
  • ELEMENT_NAME — The name of the payroll element type from PAY_ELEMENT_TYPES_F.
  • ELEMENT_INFO_ID and ELEMENT_TYPE_ID — Surrogate identifiers for the additional element information record and the associated element type, respectively, exposed under the "IDS" comment block for join and drill-down purposes.
  • ATTRIBUTE_CATEGORY — The descriptive flexfield context for the underlying record, supporting extensibility through the DFF segment columns not shown here.

Common Use Cases and Queries

Typical uses include validating element configuration, auditing processing order conflicts, and driving downstream costing or payroll integration. A representative query follows:

  • Retrieve processing order for a specific element: SELECT element_name, processing_order FROM apps.hxtfv_add_elem_info WHERE element_name = :p_element_name;
  • List all additional element info sorted by processing sequence: SELECT earning_category, absence_type, premium_type, processing_order, expenditure_type FROM apps.hxtfv_add_elem_info ORDER BY processing_order;
  • Audit element-to-expenditure mapping: SELECT element_name, expenditure_type FROM apps.hxtfv_add_elem_info;

Because the view applies SYSDATE-based effective date filters, queries reflect only currently effective records. Historical analysis requires querying the underlying effective-dated table directly.