Search Results is_proj_sub_project

Overview

PA_RELATIONSHIP_UTILS is an Oracle EBS Projects (PA) schema utility package owned by APPS and classified as an OTHER-type API. It provides the low-level validation, lookup, and structural-checking logic that governs relationships between project and task structures. In Oracle Projects, tasks and project elements can be linked through several relationship types: intersubject links, dependencies, and associations. This package centralizes the rules that determine whether such a relationship may legally be created, whether it already exists, and how structural hierarchies (parent/child, predecessors) are resolved.

The package is not a user-facing entry point; it is an internal utility layer consumed by higher-level public and private APIs. As confirmed by the ETRM dependency listing, it is referenced by PA_RELATIONSHIP_PVT, PA_PROJECT_PUB, PA_PROJECT_STRUCTURE_PVT1, PA_PROJ_STRUCTURE_PUB, PA_PROJ_ELEMENTS_UTILS, PA_TASK_PUB1, PA_TASK_PVT1, PA_TASK_UTILS, PA_PROJ_TASK_STRUC_PUB, PA_STRUCT_TASK_ROLLUP_PUB, and numerous project/task progress views. This wide fan-in indicates that PA_RELATIONSHIP_UTILS is a foundational component of the Projects relationship model, exercised whenever project elements or tasks are linked, versioned, or rolled up. Its only external package dependency is on the SYS.STANDARD package.

Key Procedures and Functions

The documentation enumerates 26 procedures and functions. Their names reveal a consistent pattern of query and validation utilities grouped by relationship category.

• Link validation: CHECK_CREATE_LINK_OK, CHECK_LINK_EXISTS, PARENT_LP_LINK_EXISTS — determine whether a link may be created and whether a link already exists.
• Dependency validation: CHECK_CREATE_DEPENDENCY_OK, CHECK_CREATE_INTRA_DEP_OK, CHECK_CREATE_INTER_DEP_OK, CHECK_DEP_EXISTS — validate intraproject and interproject dependencies and detect duplicates.
• Association validation: CHECK_CREATE_ASSOCIATION_OK, CREATE_SUB_PROJ_ASSO_OK — govern association creation, including subproject associations.
• Structural classification: IS_PROJ_TOP_PROGRAM, IS_PROJ_SUB_PROJECT, IS_AUTO_ROLLUP, DISABLE_SYS_PROG_OK, DISABLE_MULTI_PROG_OK — classify project elements and determine rollup/disable eligibility.
• Version resolution: GET_LATEST_PARENT_VER_OBJ_ID, GET_LATEST_PARENT_TASK_VER_ID, GET_LATEST_CHILD_VER_ID — retrieve the current version identifiers of parent and child objects.
• Hierarchy navigation: GET_PREDECESSORS, GET_PARENTS_CHILDS, DISPLAY_PREDECESSORS — return predecessor and parent/child sets used by progress and scheduling views.

No parameter lists are documented in the ETRM metadata; each routine should be treated as an internal helper whose signature is defined by the package specification.

Tables Accessed

The package reads from core Projects relationship and structure tables through APPS synonyms:

• PA_OBJECT_RELATIONSHIPS — the primary store of links, dependencies, and associations; the focus of the existence and creation checks.
• PA_PROJECTS_ALL, PA_PROJ_ELEMENTS, PA_PROJ_ELEMENT_VERSIONS — supply project and element identity and version context.
• PA_PROJ_ELEM_VER_STRUCTURE, PA_PROJ_STRUCTURE_TYPES, PA_STRUCTURE_TYPES, PA_TASKS — define the permitted hierarchy and structure types used in validation.
• PA_PROJ_WORKPLAN_ATTR — provides workplan attributes relevant to rollup behaviour.
• DUAL — used for single-row evaluations and simple checks.

Usage Notes

PA_RELATIONSHIP_UTILS is typically invoked from higher-level packaged APIs rather than directly from forms or concurrent programs. The public entry points that project managers and developers use — PA_PROJECT_PUB, PA_PROJ_STRUCTURE_PUB, PA_TASK_PUB1, and PA_RELATIONSHIP_PVT — delegate relationship and dependency checks to this package. Its functions are also referenced by database views such as PA_LATEST_PROJ_TASK_PROG_V, PA_PROGRESS_HIST_DET_V, and the structure version views, meaning the routines execute whenever those views are queried.

Because the package is classified as OTHER and depends only on SYS.STANDARD, Oracle does not guarantee a formalized public API contract. Customizations should not call it directly where a documented public API exists; instead, custom code should use the referencing public packages. When extending relationship logic, the appropriate pattern is to place validations in this utility layer so that all consumers inherit consistent behaviour.