Search Results p_pos_structure_version_id

Overview

The APPS.PER_POS_STRUCTURE_VERSION_API package is a public, server-side PL/SQL API belonging to the Oracle Human Resources (PER) product family. Its business purpose is to manage the lifecycle of position structure versions — the dated, versioned records that define the composition and hierarchy of a position structure at a given point in time. Position structures form the organizational backbone against which positions are defined, graded, and reported, and versioning allows an enterprise to date-track structural reorganizations without destroying historical definition data.

The package follows the standard Oracle EBS API pattern: it exposes a small set of public, transactional entry points that are declared in the package specification and implemented in the body. Each entry point accepts date-effective inputs, validates them, performs the necessary DML against the underlying base tables, and returns both a surrogate identifier and an object version number to the caller. The object version number supports Oracle’s optimistic locking convention, allowing callers to detect concurrent modification when a row is subsequently updated or deleted.

The ETRM metadata records this object as an API classification package owned by APPS, with three documented procedures and references to two base tables. The package is also documented as being referenced by two other packages, indicating that it participates in a wider dependency chain within the HR schema rather than being an isolated utility.

Key Procedures and Functions

Three public procedures constitute the documented interface of the package:

• CREATE_POS_STRUCTURE_VERSION — Inserts a new version row for a given position structure. It accepts an effective date, the owning position structure identifier, a from-date, and a version number, and optionally a source structure version to copy from, a to-date, and standard WHO/audit attributes (request id, program application id, program id, program update date). It returns the newly generated p_pos_structure_version_id along with an object version number and a gap-warning indicator. The gap warning reports whether the supplied date range leaves a chronological gap against existing versions. This is the procedure most commonly associated with the search term p_pos_structure_version_id, since the parameter is the primary OUT value sought by callers.
• UPDATE_POS_STRUCTURE_VERSION — Modifies an existing position structure version, using the object version number for optimistic concurrency control and the effective date to enforce date-tracked correction semantics.
• DELETE_POS_STRUCTURE_VERSION — Removes a position structure version, again validating the object version number before the delete is committed.

Because the package is an API rather than a business process owner, it performs validation and row manipulation only; it does not itself raise business events or orchestrate workflow.

Tables Accessed

Two tables are documented as being accessed through APPS synonyms:

• PER_POSITION_STRUCTURES — The parent entity holding the header definition of a position structure. The API reads this table to validate that the target structure exists and is valid on the supplied effective date before permitting a version to be created, updated, or deleted.
• PER_POS_STRUCTURE_VERSIONS — The child entity holding the dated version records. This is the primary table written by the package; the local variable l_pos_structure_version_id is anchored to its primary key column, and the object version number is sourced from the same row.

The ETRM excerpt shows the package body delegating to an underlying business-layer package (per_pos_structure_version_bk1) for the actual DML, a standard two-tier API pattern in EBS that separates the public interface from the implementation logic and enforces consistent validation.

Usage Notes

The package is typically invoked from Oracle Forms (the Position Structure and Position Hierarchy maintenance windows), from concurrent programs that load or reorganize position structures, and from customer-developed PL/SQL that must create or amend structures in a controlled, date-effective manner. Callers should always supply a valid p_effective_date, respect the returned p_object_version_number for subsequent updates, and inspect p_gap_warning before committing. Because the procedure is transactional, callers should wrap invocations in an explicit savepoint where partial rollback may be required, mirroring the internal savepoint used in the body. Direct DML against the two base tables is not supported and bypasses the validation and object versioning logic this API provides.