Search Results get_line_status

Overview

The APPS.PER_RI_CREATE_HIER_ELEMENT package body is a PL/SQL utility shipped with Oracle E-Business Suite (12.1.1 and 12.2.2) that supports the Oracle HRMS "Create Hierarchy Element" data pump process. Its role is to load organization hierarchy structures — organizational units and their parent/child relationships — into the HR data model through the standard Oracle Data Pump (DP) batch-line mechanism used during bulk HRMS setup and migration. The package name reflects its HRI (HR Intelligence / HR Integration) origin, and its header indicates it has not been customised by customers (noship), confirming it is a delivered application object owned by APPS.

In practical terms, the package operates as the technical engine behind the hierarchy-element data pump, translating staged batch-line records into the base HR tables that define organization structures and versions. Because it is classified as OTHER rather than a public API, it is intended for internal use by the data pump framework rather than direct invocation by customer code.

Key Procedures and Functions

The package exposes two documented program units:

• GET_LINE_STATUS — A function that accepts a view name and a data pump batch-line identifier and returns the two-character line status for that batch line. It builds a dynamic SQL statement at runtime against the caller-supplied view (for example, a create-hierarchy-element view) and retrieves the line_status column for the specified batch line. This allows the pumping process to inspect the current processing state of an individual hierarchy-element line without hard-coding the source view.
• INSERT_BATCH_LINES — A procedure that performs the core insertion of hierarchy-element batch lines. It accepts a batch identifier together with an extensive set of parameters controlling the business group, user sequence, link value, effective/from dates, view-all-organizations flag, end-of-time date, HR and Payroll installation flags, position-control flag, warning flag, parent and child organization names, language code, organization structure version user key, and security profile name. It resolves organization structure version identifiers and business group context internally before persisting the hierarchy element rows.

Tables Accessed

The documented table references are intentionally narrow, reflecting the package's responsibility for resolution and staging rather than mass data manipulation:

• HR_PUMP_BATCH_LINE_USER_KEYS — Stores user-key values associated with data pump batch lines, enabling mapping between external user keys and internal identifiers during hierarchy-element loading.
• PER_ORGANIZATION_STRUCTURES — Holds organization structure definitions; the package queries it to resolve the structure that owns the hierarchy being created.
• PER_ORG_STRUCTURE_VERSIONS — Holds dated versions of organization structures; queried to obtain the correct organization_structure_id for a given business group and effective context.
• DUAL — Used for singleton selects and expression evaluation within the PL/SQL logic.

The package also reads the view supplied to GET_LINE_STATUS and the data pump view HRDPV_CREATE_HIERARCHY_ELEMENT internally to obtain organization-structure version user keys.

Usage Notes

Because this package is classified as OTHER and is referenced by zero other packages, it is not a public integration surface. It is invoked by the HRMS data pump infrastructure when creating organization hierarchy elements in bulk — for example, during initial HRMS configuration, organization hierarchy migration, or business group setup. Practitioners searching for get_line_status are typically diagnosing data pump failures or verifying the status of a hierarchy-element batch line. Custom code should not call these program units directly; instead, the supported path is to run the delivered Create Hierarchy Element data pump through its standard concurrent program or the HRMS configuration interfaces, which manage batch-line staging and error reporting. Any custom diagnostics should treat the package's dynamic SQL (which accepts a view name) as a potential SQL-injection consideration and rely only on trusted delivered views.