Search Results per_org_structure_versions_pkg




Overview
Explore in AI Chat

Overview

PER_ORG_STRUCTURE_VERSIONS_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that governs the creation, maintenance, and validation of dated versions of organization structures (organization hierarchies) within Oracle HRMS. Organization structures in EBS are time-tracked entities: each structure can have one or more version rows, each defined by a date-from and date-to range, a version number, and an associated set of organization structure elements that describe parent-child relationships between organizations. This package encapsulates the business rules that keep those versions internally consistent — preventing date overlaps, detecting gaps between consecutive versions, enforcing unique version numbering, and cascading changes to the related element tables.

The package is declared with AUTHID CURRENT_USER and carries a header revision string (peosv01t.pkh) indicating it forms part of the standard Oracle HRMS delivered codebase. It is classified in ETRM as an OTHER API, meaning it is not a formally published open interface but is nonetheless a stable, documented component invoked internally by the HRMS forms and by other HRMS processing logic. No other packages in the documented inventory reference it, confirming its role as a leaf-level utility rather than a shared framework component.

Key Procedures and Functions

  • GET_NEXT_FREE_NO — Returns the next available version number for a given organization structure version identifier, supporting automatic version numbering during insert.
  • CHECK_DATE_GAPS — Evaluates the date range supplied for a version and returns a warning when a gap exists between the new or modified version and adjacent versions of the same structure. The warning is returned through an IN OUT NOCOPY parameter, which is the object named in the user's search.
  • CHECK_VERSION_NUMBER — Validates that the supplied version number is acceptable for the given organization structure, guarding against duplicates.
  • CHECK_OVERLAP — Detects whether the proposed date-from and date-to range overlaps an existing version, and returns a closedown-related warning through an IN OUT NOCOPY parameter when the end-of-time boundary is affected.
  • COPY_ELEMENTS — Duplicates the organization structure elements from a source structure version into a target structure version, enabling a new version to be seeded from an existing one.
  • INSERT_ROW — Creates a new version row, orchestrating the validation routines above and returning generated identifiers and warnings through NOCOPY parameters.
  • LOCK_ROW — Acquires a row-level lock on the version record for concurrency control during update or delete.
  • UPDATE_ROW — Modifies an existing version row while re-applying version and date validations.
  • PRE_DELETE_CHECKS — Performs referential and business-rule validation before a version is removed.
  • UPDATE_COPIED_VERSIONS — Adjusts copied version records, typically reconciling identifiers after a copy operation.
  • DELETE_ROW — Removes a version row and its dependent element data.

Tables Accessed

Usage Notes

The package is most commonly invoked indirectly from the Organization Structures form in Oracle HRMS whenever a user creates, copies, updates, or deletes a structure version. In that flow, CHECK_DATE_GAPS and CHECK_OVERLAP surface warnings to the user interface through their IN OUT parameters rather than raising hard exceptions, allowing the user to accept a gap or overlap with confirmation. CHECK_VERSION_NUMBER enforces the uniqueness constraint.

Custom code and data-migration scripts that manipulate organization structures directly should call this package rather than performing DML against the underlying tables, because the package maintains the synchronization between base and _S tables, manages the version numbering sequence, and preserves the date-range integrity rules. Because it is an OTHER-classified API, Oracle does not guarantee interface stability across releases; implementers should validate behavior when upgrading between 12.1.1 and 12.2.2 and avoid depending on undocumented parameter signatures. All execution must occur in the APPS schema or in a schema with appropriate synonyms and grants.