Search Results p_parent_position_id

Overview

The APPS.HR_POS_HIERARCHY_ELE_API package body provides the programmatic interface for maintaining the positional hierarchy structures used by Oracle HRMS. In Oracle E-Business Suite 12.1.1 and 12.2.2, it is the API layer that governs the rows of PER_POS_STRUCTURE_ELEMENTS, the table that stores the parent-child relationships between positions within a position structure version. Each row of that table records a single hierarchy element: a parent position, a subordinate position, the structure version to which the relationship belongs, and the effective dating and object version columns required for Oracle HRMS date-tracked entities.

The package is classified as an API in the ETRM repository and is owned by the APPS schema. It exposes both a public and an internal procedure set, following the standard Oracle HRMS pattern in which the public procedures apply validation, date-track logic, and business-group security, while the internal procedures perform the actual DML. A caller supplying the search term p_parent_position_id is interacting with the CREATE_POS_HIERARCHY_ELE entry point, where that parameter identifies the parent position for the element being created.

Key Procedures and Functions

Six documented procedures are exposed by the package body:

• CREATE_POS_HIERARCHY_ELE — Creates a new position hierarchy element linking a parent position to a subordinate position within a specified position structure version. It accepts the parent position identifier (p_parent_position_id), the structure version identifier, the subordinate position identifier, the business group, the HR installation flag, and an effective date, and returns the new structure element identifier and object version number. Validation is controlled by a p_validate flag, allowing the caller to roll back a test execution.
• UPDATE_POS_HIERARCHY_ELE — Modifies an existing hierarchy element, applying the standard date-track update semantics so that changes are recorded against the correct effective date range and the object version number is incremented.
• DELETE_POS_HIERARCHY_ELE — Removes a hierarchy element, either logically by end-dating the record or physically, according to the date-track conventions of the underlying entity.
• CREATE_POS_HIER_ELEM_INTERNAL — The internal counterpart to the create operation, performing the insert into PER_POS_STRUCTURE_ELEMENTS without the full public validation layer. It is intended for use by the package itself and by trusted internal callers.
• UPDATE_POS_HIER_ELEM_INTERNAL — Performs the internal update of an existing hierarchy element row.
• DELETE_POS_HIER_ELEM_INTERNAL — Performs the internal deletion of a hierarchy element row.

The create procedure declares cursors that read pre-existing elements for the same subordinate and structure version, and a validation cursor that detects the case where the proposed parent already appears as a child elsewhere in the hierarchy, guarding against circular relationships.

Tables Accessed

The package operates against PER_POS_STRUCTURE_ELEMENTS, accessed through its APPS synonym. This table holds the parent position, subordinate position, business group, position structure version, effective dates, and object version number for each hierarchy element. The package reads it to retrieve existing element identifiers and object version numbers, to validate that the proposed parent is not already a descendant of the proposed subordinate, and writes to it for all create, update, and delete operations.

Usage Notes

The package is typically invoked from Oracle HRMS position hierarchy maintenance forms, from concurrent programs that build or reorganize position structures, and from custom PL/SQL that programmatically maintains positional hierarchies. Callers should supply a valid effective date, a business group consistent with the positions involved, and the correct position structure version. Because hierarchy maintenance is date-tracked, updates and deletes should be performed through the public procedures rather than by direct DML on PER_POS_STRUCTURE_ELEMENTS. The ETRM metadata records that this package is referenced by one other package, indicating that it is consumed by higher-level HRMS APIs rather than being an end-user entry point. All calls should be followed by a commit or rollback in the normal Oracle EBS transaction pattern, with p_validate set to true for dry-run verification before committing changes.