Search Results pa_planning_resource_utils




Overview
Explore in AI Chat

Overview

PA_PLANNING_RESOURCE_UTILS is an internal PL/SQL utility package in the Oracle E-Business Suite Projects (PA) module, owned by the APPS schema. It provides reusable helper logic for project planning and resource management, principally the retrieval and validation of resource-related codes and attributes used across resource lists, resource assignments, and resource breakdown structures. The package is classified under ETRM as an OTHER API, meaning it is not a public, supported interface but rather a shared internal library consumed by other Project applications code. Its source header indicates a 2006 vintage (PARPRLUS.pls 120.2), and it remains present through EBS 12.1.1 and 12.2.2.

The package is referenced by 25 other packages, confirming its role as a foundation utility rather than a user-facing entry point. Functions such as GET_RES_MEMBER_CODE, GET_MEMBER_FIN_CAT_CODE, and GET_RESOURCE_CODE translate numeric identifiers held on planning rows into the descriptive codes planners and downstream processes require.

Key Procedures and Functions

The documented interface comprises 55 procedures and functions. The most prominent groups are:

All standard "who" columns (created_by, creation_date, last_updated_by, last_update_date, last_update_login) are initialised from FND_GLOBAL.

Tables Accessed

The package reads and writes the following documented tables through APPS synonyms:

Usage Notes

Because PA_PLANNING_RESOURCE_UTILS is an internal utility rather than a published API, it is normally invoked indirectly from Project Planning and Resource Management forms, concurrent programs, and other PA packages that need to resolve or validate a plan resource combination. Custom code should prefer documented public APIs; where PA_PLANNING_RESOURCE_UTILS must be called, the lookup functions are read-only and safe to invoke, while any routine performing inserts or updates inherits the calling transaction's commit semantics. The package relies on FND_GLOBAL session context, so it must be executed within an initialized EBS session.