Search Results pa_client_extn_proj_status




Overview
Explore in AI Chat

Overview

PA_CLIENT_EXTN_PROJ_STATUS is an APPS-owned PL/SQL package body classified in the ETRM repository under the generic API category "OTHER." It belongs to the Oracle Projects (PA) module and serves as a client extension hook that validates project status changes before they are committed within Oracle E-Business Suite. Rather than presenting a general-purpose public API, the package supplies validation logic that the Oracle Projects framework can invoke at defined extension points, allowing status transitions on projects to be screened against installation-specific business rules. The package body is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, and it depends on the Oracle Workflow message dictionary (FND_MSG_PUB), the project request layer (PA_PROJECT_REQUEST_PVT), and the core project setup tables (PA_PROJECTS_ALL, PA_PROJECT_STATUSES, PA_PROJECT_TYPES_ALL). It is referenced by two other database objects, confirming its role as a subordinate extension component rather than a top-level entry point.

Key Procedures and Functions

The ETRM metadata records two documented procedures within this package body. The package contains no inventoried functions. Parameter lists are not published in the available metadata and are therefore not reproduced here.

  • VERIFY_PROJECT_STATUS_CHANGE — The principal validation routine. Its purpose is to evaluate a proposed change to a project's status and determine whether that transition is permitted. It inspects the current and target statuses together with project attributes such as the project type, applying whatever client-specific criteria the implementation has defined. The result is consumed by the calling Projects process to accept or reject the status change.
  • CHECK_WF_ENABLED — A supporting routine that determines whether Oracle Workflow-driven processing is enabled for the relevant status change path. This governs whether workflow messaging and notification infrastructure should be engaged during the validation cycle, and it explains the package's dependency on FND_MSG_PUB.

Tables Accessed

The package reads from three core Oracle Projects configuration tables, all resolved through APPS synonyms. It does not appear to write to these tables directly; the actual status update is performed by the framework, with this package acting in an advisory validation capacity.

  • PA_PROJECTS_ALL — Supplies the project record under evaluation, including its current status and identifying attributes, so the validation routine can reason about the proposed transition.
  • PA_PROJECT_STATUSES — Defines the set of valid project statuses configured for the installation, providing the reference list against which a target status is checked.
  • PA_PROJECT_TYPES_ALL — Provides project type definitions, allowing validation rules to vary by project type where the client's business rules require it.

Additional dependencies include PA_PROJECT_REQUEST_PVT, the project request public API, which establishes the context in which validation occurs, and FND_MSG_PUB for message and notification handling.

Usage Notes

PA_CLIENT_EXTN_PROJ_STATUS is not intended to be called directly from custom forms or concurrent programs. It is a client extension package: Oracle Projects invokes its validation logic automatically when a project status change is processed, provided the extension point has been enabled and the package body customized. Implementations that require restrictions such as prohibiting particular status transitions for certain project types, enforcing approval prerequisites, or suppressing workflow notifications under defined conditions modify the body of VERIFY_PROJECT_STATUS_CHANGE to encode those rules. Because the package depends on PA_PROJECT_REQUEST_PVT and PA_PROJECTS_ALL, any customization must respect the transaction context established by the project request layer. The package is referenced by two other database objects, so changes to its behavior can influence callers beyond the immediate status change flow and should be regression-tested against all dependent code. Because only the object inventory, not the source, is documented in ETRM, parameter signatures and exact invocation semantics should be confirmed against the deployed package specification in the target environment before extending it.