Search Results per_pse_bus




Overview
Explore in AI Chat

Overview

PER_PSE_BUS is a PL/SQL business logic package in the APPS schema that supports Oracle E-Business Suite's Position Security Profile functionality, which is part of the Oracle HRMS (Human Resources Management System) Enterprise module. The package name derives from "PER" (the HRMS product prefix) and "PSE" (Position Structure Elements / Position Security Elements), and the "_BUS" suffix follows Oracle's standard naming convention indicating that the package contains business rules and validation logic separated from the underlying database-level operations.

Within the Oracle EBS architecture, many HRMS entities implement a layered pattern in which a *_BUS package encapsulates business rules, a *_INS, *_UPD, and *_DEL package handle row-level DML, and a shadow table (*_SHD) tracks audit history. PER_PSE_BUS participates directly in this pattern: the metadata confirms that PER_PSE_INS, PER_PSE_UPD, and PER_PSE_DEL all reference PER_PSE_BUS, and that PER_PSE_BUS itself depends on the shadow table PER_PSE_SHD. The package is classified as OTHER in the ETRM API classification scheme, meaning it is an internal supporting package rather than a formally published public API.

Key Procedures and Functions

The ETRM metadata documents five entry points. No parameter lists are published, and none should be assumed.

  • SET_SECURITY_GROUP_ID — Establishes the Business Group / security group context for the current session or operation. Because HRMS security-profile data is partitioned by security group, this procedure ensures subsequent validation or query activity operates against the correct organizational partition.
  • RETURN_LEGISLATION_CODE — Returns the legislation code (the country-specific rule set, such as US, GB, or CA) associated with the record or context being processed. Legislation code drives which validation rules are appropriate, since position structure and security rules vary by legislative environment.
  • INSERT_VALIDATE — Applies business validation logic before a new position security record is inserted. Typically invoked by PER_PSE_INS as a pre-insert gate.
  • UPDATE_VALIDATE — Applies validation logic when an existing position security record is modified, invoked by PER_PSE_UPD.
  • DELETE_VALIDATE — Applies validation logic before deletion, invoked by PER_PSE_DEL, ensuring that referenced or protected records are not removed improperly.

Tables Accessed

Four base tables are referenced through APPS synonyms:

  • HR_ALL_POSITIONS_F — The core positions table. Read to confirm that a position referenced by a security profile or structure element exists and is valid.
  • PER_POS_STRUCTURE_ELEMENTS — Position structure elements (hierarchies). Read to validate that security assignments align with valid structure members.
  • PER_POS_STRUCTURE_VERSIONS — Date-effective versions of position structures. Accessed to resolve the correct structure version for the effective date of the transaction.
  • PER_SECURITY_PROFILES — The security profile definitions themselves. Read to validate profile attributes and relationships during insert, update, and delete operations.
  • PER_PSE_SHD — The shadow/audit table for the PER_PSE entity, listed as a dependency of the package, supporting historical tracking of changes.

Usage Notes

PER_PSE_BUS is not intended for direct invocation by end users or typical custom extensions. It is an internal layer called by the DML packages PER_PSE_INS, PER_PSE_UPD, and PER_PSE_DEL, which in turn are triggered by the Position Security Profile forms and by concurrent programs that maintain position security data. Developers extending HRMS position security should call the documented public APIs or *_INS/*_UPD/*_DEL wrappers rather than PER_PSE_BUS directly. When debugging validation failures on position security records, the *_VALIDATE procedures are the appropriate place to inspect. Because the package reads the security group context through SET_SECURITY_GROUP_ID, callers in multi-organization or multi-Business-Group environments must ensure the correct security group is initialized before the package is executed. Behavior is consistent across EBS 12.1.1 and 12.2.2, as the object remains VALID in the APPS schema in both releases.