Search Results per_position_structure_api




Overview
Explore in AI Chat

Overview

PER_POSITION_STRUCTURE_API is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Oracle Human Resources (PER) product family. Its business function is to provide a supported, validated programmatic interface for maintaining position hierarchies within the enterprise. In Oracle HRMS, positions are organized into hierarchical structures that model reporting lines, supervisory relationships, and organizational reporting paths. Each position structure defines a named hierarchy — a tree of positions — that the application uses to drive approvals routing, security profile access, and reporting rollups.

Rather than allowing direct DML against the underlying position structure tables, Oracle exposes this package so that all insert, update, and delete activity passes through the standard HRMS API layer. The package is classified as an API in the ETRM documentation for release 12.2.2 and is reported with a status of VALID in the APPS schema. It depends upon the shared HR_API utility package and the SYS STANDARD package, which indicates that it follows the established Oracle HRMS API coding conventions: column validation, business rule enforcement, and consistent handling of the WHO columns and object version numbers. Two companion objects reference it — PER_POSITION_STRUCTURE_SWI, which is the generated service web interface wrapper, and PER_POSITION_STRUCTURE_API itself as listed in the dependency tree.

Key Procedures and Functions

The ETRM metadata documents four callable procedures or functions in this package:

  • CREATE_POSITION_STRUCTURE — Creates a new position structure definition, establishing a named hierarchy to which positions can later be assigned.
  • CREATE_POS_STRUCT_AND_DEF_VER — Creates a position structure together with its defining version in a single call. This variant is used when the structure and its initial version record must be established atomically.
  • UPDATE_POSITION_STRUCTURE — Modifies attributes of an existing position structure, such as its name or descriptive information, subject to HRMS validation rules.
  • DELETE_POSITION_STRUCTURE — Removes a position structure definition. Because structures may be referenced by position hierarchy records and security profiles, deletion is subject to the referential and business rule checks enforced by the API layer.

All four entry points follow the Oracle HRMS API pattern of accepting business attribute parameters alongside the standard API control parameters. Parameter lists are not reproduced here; callers should consult the package specification in the target release.

Tables Accessed

The package operates against PER_POSITION_STRUCTURES, accessed through the APPS synonym. This table stores the header-level definition of each position structure — its identifying information and descriptive attributes. The create routines insert new rows, the update routine modifies them, and the delete routine removes them. The procedure CREATE_POS_STRUCT_AND_DEF_VER also implies insert activity in the associated definition/version table that holds the versioned hierarchy detail used to resolve the structure at a point in time. All access is performed through the API rather than by direct DML, ensuring that validations and WHO audit columns are populated correctly.

Usage Notes

This package is typically invoked from Oracle HRMS setup forms, from concurrent programs that load or maintain position hierarchy data, and from custom PL/SQL or Java code performing bulk maintenance or integration with external systems. Oracle's documented practice is to call the API rather than write directly to PER_POSITION_STRUCTURES. The presence of the associated PER_POSITION_STRUCTURE_SWI package indicates that the structure maintenance functions are also exposed through Oracle's service web interface layer, commonly surfaced through the integrated SOA Gateway or similar web service publication mechanisms.

Because the package depends on HR_API, callers should expect standard HRMS API behavior: date-tracked or version-tracked operations where applicable, validation of effective dates, and error reporting through the FND_MESSAGE / HR_API error stack. Custom code should always check the return status rather than assuming success. As with all Oracle HRMS APIs, the package is only supported for documented entry points; undocumented internal procedures should not be called directly. In R12.1.1 and R12.2.2 the object resides in APPS and is reported VALID, so no recompilation or remediation is required in a standard installation.