Search Results per_org_structure_versions

Overview

The PER_ORG_STRUCTURE_VERSIONS table is a core data object within the Oracle E-Business Suite Human Resources (HRMS) module, specifically under the PER product family. Its primary function is to provide version control for organization hierarchies. In Oracle EBS, an organization hierarchy (defined in PER_ORGANIZATION_STRUCTURES) is a flexible framework for reporting and analysis. Since these reporting structures can change over time—due to reorganizations, acquisitions, or other business events—this table stores distinct versions of a hierarchy. Each version represents the state of the organizational reporting relationships at a specific point in time, allowing for accurate historical reporting and security rule enforcement based on past structures. This versioning mechanism is critical for maintaining data integrity across modules that rely on organizational context, such as Projects, Grants Accounting, and advanced HR processes.

Key Information Stored

The table stores metadata that defines and manages each hierarchy version. While the full column list is not detailed in the provided metadata, the primary and foreign key relationships reveal its critical components. The primary key is ORG_STRUCTURE_VERSION_ID, a unique identifier for each version record. Essential foreign keys include ORGANIZATION_STRUCTURE_ID, which links back to the parent hierarchy definition in PER_ORGANIZATION_STRUCTURES, and BUSINESS_GROUP_ID, which ties the version to a specific HR business group for security and data partitioning. Other crucial columns typically found in this table, based on standard implementation, include VERSION_NUMBER, DATE_FROM (the effective start date of the version), and DATE_TO (the effective end date). The status of a version (e.g., 'Active', 'Inactive') is also commonly stored to indicate its current usability.

Common Use Cases and Queries

A primary use case is retrieving the active organization hierarchy version for reporting or security profile generation. For example, to find all active versions for a specific business group, a query might be: SELECT version_number, date_from, date_to FROM per_org_structure_versions WHERE business_group_id = :p_bg_id AND sysdate BETWEEN date_from AND NVL(date_to, sysdate);. Another common scenario is historical analysis, such as determining which hierarchy version was in effect for an employee's assignment on a past date. Integration points are significant; for instance, the Projects module (PA) uses a specific org structure version for defining indirect rate schedules (as referenced by PA_IND_RATE_SCHEDULES_ALL_BG). Developers often join this table with PER_ORG_STRUCTURE_ELEMENTS to get the actual parent-child relationships for a given point-in-time version.

Related Objects

As indicated by the foreign key metadata, PER_ORG_STRUCTURE_VERSIONS is a central hub with numerous dependencies. Its most direct child is the PER_ORG_STRUCTURE_ELEMENTS table, which stores the actual parent-child organization links for each version. It is fundamentally linked to its parent definition table, PER_ORGANIZATION_STRUCTURES. Crucially, it is referenced by several other EBS modules, demonstrating its cross-functional importance:

• Projects (PA): PA_IMPLEMENTATIONS_ALL, PA_IND_RATE_SCHEDULES_ALL_BG, PA_IND_RATE_SCH_REVISIONS, and PA_PROJECT_ASSIGNMENTS.
• Grants Accounting (IGW): IGW_IMPLEMENTATIONS_ALL (for both APR and PRP structures).
• U.S. Federal HR (GHR): GHR_MASS_REALIGNMENT and GHR_MASS_TRANSFERS, which track changes against old versions.

This wide integration underscores that the table is not merely an HR artifact but a foundational element for enterprise-wide configuration and reporting.