Search Results chk_for_org_in_hierarchy

Overview

HR_SA_ORG_INFO is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM documentation as an OTHER-type API rather than a formally published public interface. Its name follows the HR_SA naming convention associated with Oracle HRMS localization or supplementary organization components, and its documented object status is VALID in both Oracle EBS 12.1.1 and 12.2.2. The package provides utility logic for interrogating organization hierarchies and organization identity attributes stored in the Oracle Human Resources core tables. It does not create or maintain organizations; instead it answers structural questions about them, such as whether a given organization participates in a named hierarchy, which version of a hierarchy is current, and what employer name is associated with an organization record. Because these questions recur across HRMS setup, reporting, and localization processing, HR_SA_ORG_INFO functions as a shared internal service routine that centralizes hierarchy resolution logic rather than duplicating it in every calling program.

Key Procedures and Functions

The ETRM metadata documents seven procedures and functions in the package. The procedure NAMED_HIERARCHY deals with named hierarchy processing, providing the package's core entry point for hierarchy-based logic. LATEST_NAMED_HIERARCHY_VERS serves the related purpose of resolving the most recent version of a named hierarchy, so callers can work against current structure definitions rather than superseded ones. ORG_EXISTS_IN_HIERARCHY determines whether a specified organization is present within a given hierarchy. CHK_FOR_ORG_IN_HIERARCHY is a closely related validation routine that performs the same class of membership check, presumably with differences in return convention or error handling appropriate to different calling contexts. GET_EMPLOYER_NAME returns the employer name attribute for an organization, drawing on organization information rather than on a display name alone. Two of the seven documented routines are not enumerated in the available excerpt; no parameter lists are reproduced here because they are not part of the supplied metadata, and parameter signatures should be confirmed against the deployed package specification in the target instance.

Tables Accessed

The package reads and writes through APPS synonyms rather than base schema tables. HR_ALL_ORGANIZATION_UNITS supplies the organization definitions that underpin every membership and name check. HR_ORGANIZATION_INFORMATION holds the descriptive and classifying attributes attached to an organization, and is the source for employer-name resolution. PER_ORG_STRUCTURE_ELEMENTS and PER_ORG_STRUCTURE_VERSIONS provide the hierarchy element and version data required by NAMED_HIERARCHY, LATEST_NAMED_HIERARCHY_VERS, ORG_EXISTS_IN_HIERARCHY, and CHK_FOR_ORG_IN_HIERARCHY. FND_SESSIONS is referenced for session context, which is consistent with an API that may depend on the effective user, business group, or date-tracked session state. DUAL supports scalar evaluation and simple return expressions. The dependency listing further confirms that HR_SA_ORG_INFO references APPS.HR_ORGANIZATION_UNITS, and that it is self-referenced within the APPS schema.

Usage Notes

HR_SA_ORG_INFO is not referenced by any documented public package, and the ETRM record shows zero dependent packages, indicating that it is invoked directly from forms, concurrent programs, or customer extensions rather than through a published API layer. Typical invocation is from localization or country-specific HRMS processing, from concurrent programs that report organization hierarchy membership, and from custom PL/SQL that needs a consistent answer to hierarchy and employer-name questions. Because the package touches session and date-tracked organization structures, callers should supply organization and hierarchy identifiers that are valid for the session's business group. Before use in a customization, the package specification should be reviewed to confirm exact signatures, and the object should be treated as an internal implementation detail subject to change rather than a guaranteed public interface.