Search Results hr_organization_internal




Overview
Explore in AI Chat

Overview

HR_ORGANIZATION_INTERNAL is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides the low-level internal API for creating and maintaining organization definitions within Oracle HRMS. Its documented purpose is to support the upload (creation) and maintenance of organization records, specifically the business units that participate in the Multi-Org model, such as operating units. The package encapsulates the logic required to insert and update rows in the core organization tables while preserving the date-tracked (datetrack) semantics that Oracle HRMS applies to all organization records.

The single documented entry point, HR_ORG_OPERATING_UNIT_UPLOAD, is commonly encountered by implementers who are loading operating units from external sources, conversion spreadsheets, or interface tables. Because organizations must exist in HRMS before they can be assigned as operating units or referenced by other EBS products, this package is frequently referenced in setup and data-migration scripts that pre-date or supplement the standard organization APIs. It is classified in ETRM as an OTHER API, indicating that it is an internal rather than a fully supported public interface, and it should be used with an understanding of its restricted scope.

Key Procedures and Functions

The package exposes one documented procedure:

  • HR_ORG_OPERATING_UNIT_UPLOAD — Creates or maintains an operating unit organization record in HRMS. Its parameter list includes a name, an organization identifier, a date-from and date-to pair that define the datetracked effective period of the record, an internal/external classification flag, and an operating unit attribute. The procedure accepts the organization identifier as an IN OUT parameter, allowing the caller to either supply an existing identifier for maintenance or receive the newly generated identifier after a create operation.

No additional procedures or functions are documented in the ETRM metadata for this package, and the specification in the source header confirms that HR_ORG_OPERATING_UNIT_UPLOAD is the sole exposed program unit. The lack of documented helper routines means that all date-track validation and organization-information handling is internal to the package body.

Tables Accessed

ETRM identifies two base tables referenced through APPS synonyms:

  • HR_ALL_ORGANIZATION_UNITS — The primary organization table holding the organization name, identifier, and effective dates. The upload procedure inserts or updates the operating unit row in this table, which is the parent record for all organization-related attributes.
  • HR_ORGANIZATION_INFORMATION — The flexible attribute table that stores additional organization classified information in name/value pairs, such as the operating unit flag or classification. The procedure writes the operating-unit-specific attribute here so that the organization is recognized as an operating unit by downstream Multi-Org logic.

Because these tables are date-tracked, the procedure must manage the effective start and end dates consistently to avoid overlapping or orphaned records.

Usage Notes

HR_ORG_OPERATING_UNIT_UPLOAD is typically invoked from custom PL/SQL conversion scripts, SQL*Loader post-load procedures, or interface programs that create operating units during an implementation. It is not generally exposed through a standard concurrent program or a delivered form; the standard Oracle HRMS organization windows and the public HR_ORGANIZATION_API are the preferred route for interactive setup. When the package is called directly, the caller must supply valid date ranges and ensure that any required classification or location data is already present, since the procedure writes only to the two documented tables.

Given its classification as an internal API and its reference to only two tables, the package should be treated as an unsupported entry point. Oracle EBS 12.1.1 and 12.2.2 retain this specification, but because the implementation is subject to change without notice, custom code that depends on it should be isolated and regression-tested during patching or upgrades. Where possible, the supported HR_ORGANIZATION_API or the Multi-Org setup forms should be used instead.