Search Results pa_project

Overview

APPS.PA_CC_CA is a public Oracle Projects client extension package that supports cost accrual identification within the Oracle E-Business Suite Projects application. Its stated purpose, per the source header documentation, is to identify cross-charged projects that use cost accrual during revenue generation. The package is declared with AUTHID CURRENT_USER, meaning its unqualified database references resolve under the privileges of the invoking session rather than the package owner, which is standard practice for Oracle Projects client extensions that must respect the caller's security context.

The package is registered in the ETRM repository under API classification OTHER, is compatible with Oracle EBS 12.1.1 and 12.2.2, and carries a public scope and active lifecycle designation. It is classified against two business entities: PA_PROJECT and PA_IC_TRANSACTION. This dual classification reflects its role at the intersection of project setup and intercompany (cross-charge) processing, where cost accrual treatment must be determined before revenue can be generated correctly. The package is documented in the Oracle Projects API's, Client Extensions, and Open Interfaces Reference (120pjapi.pdf).

Key Procedures and Functions

The package exposes a single documented procedure:

• IDENTIFY_CA_PROJECT — Identifies whether a given project is a cost accrual project. The procedure accepts a project identifier as input and returns an output flag indicating cost accrual status, with a value of Y or N. Both parameters are documented as required. The procedure is a client extension: Oracle Projects does not supply the decision logic itself, but instead calls this routine to allow an implementation to declare, according to its own business rules, which cross-charged projects should be treated as cost accrual projects during revenue generation.

The package specification contains no other documented procedures or functions, so IDENTIFY_CA_PROJECT represents the entire public contract of PA_CC_CA. The procedure name follows the package naming convention (identify_ca_project), and the output parameter carries the NOCOPY hint, consistent with performance guidance for OUT parameters in Oracle Projects extensions.

Tables Accessed

The documented ETRM metadata does not list any tables referenced directly through APPS synonyms by this package. This is consistent with the design intent of a client extension: PA_CC_CA is a stub whose body is expected to be replaced or extended by customer-specific logic. In a typical implementation, the custom body queries project and cross-charge configuration data — such as project setup attributes, intercompany billing arrangements, and cost accrual options — to derive the returned flag. Because the package is compiled with AUTHID CURRENT_USER and no APPS synonyms are documented, any table access performed by an implementation is the responsibility of that implementation and its grants, not of the seeded package. Implementers should therefore avoid assuming a fixed data model and should confirm the data sources appropriate to their own revenue and cross-charge configuration.

Usage Notes

PA_CC_CA is invoked by Oracle Projects' revenue generation processing when it must determine whether a cross-charged project uses cost accrual. It sits alongside other PA client extensions and is not called directly by end users or from standard Oracle Forms or concurrent programs — the calling application drives it. The ETRM metadata records that the package is referenced by one other package, confirming that it is consumed programmatically within the Projects code base rather than exposed through a user interface.

Because the seeded specification is the integration point, customization is performed by modifying the package body (or by supplying an implementation that conforms to the documented signature). Typical invocation occurs during revenue generation and intercompany processing for projects flagged through PA_PROJECT and PA_IC_TRANSACTION. Custom code that calls this package must grant EXECUTE to APPS and ensure that the implementing body returns a valid Y or N value, since the calling process relies on that flag to classify the project. Given the 2006 header date and absence of documented table dependencies, the package is stable and minimal, and the primary implementation risk lies in the custom body rather than in the seeded specification.