Search Results pa_cost_base_exp_types_pkg




Overview
Explore in AI Chat

Overview

PA_COST_BASE_EXP_TYPES_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite (12.1.1 and 12.2.2). It supports the Projects (PA) module's configuration of cost bases and expenditure types, and governs the relationship between a cost base structure and the expenditure types that feed it. In Projects costing, a cost base defines the set of source expenditure types from which a costing calculation draws amounts, and a cost base structure groups those bases for use in cost distribution, burdening, and rate application. This package provides the validation and lookup logic required to maintain the integrity of those definitions when users configure cost bases and expenditure types through the Projects Setup windows.

The package is classified as OTHER under the ETRM API classification scheme, meaning it is an internal, supporting package rather than a formally published public API. It is not a business API with committed parameter contracts and is not documented for direct customer invocation. Its routines are called from the setup forms and related internal processing that maintain the PA_COST_BASE_EXP_TYPES intersection records.

Key Procedures and Functions

  • CHECK_UNIQUE — Validates that a given combination of cost base structure, cost base type, and expenditure type has not already been defined. This prevents duplicate intersection rows from being created in the cost base / expenditure type relationship. It accepts the structure, base type, and expenditure type identifiers, plus a status parameter that is passed in and returned to signal whether the combination is valid and unique.
  • CHECK_STRUCTURE_USED — Determines whether a specified cost base structure is already in use, so that the calling form can block deletion or modification of a structure that would break existing configuration. It accepts the structure identifier and returns status and stage indicators that communicate the result of the check to the caller.
  • GET_DESCRIPTION — Retrieves the display description associated with a given expenditure type. This supports the user interface, where an expenditure type is presented by its descriptive text rather than by its internal identifier.

All three routines use the IN OUT NOCOPY convention for output parameters, which is characteristic of this generation of Oracle Applications PL/SQL and is intended to reduce copying overhead for the returned values.

Tables Accessed

  • PA_COST_BASE_EXP_TYPES — The primary intersection table holding valid combinations of cost base and expenditure type. CHECK_UNIQUE validates against this table, while other routines may reference it to determine current configuration.
  • PA_EXPENDITURE_TYPES — The expenditure type definition table. GET_DESCRIPTION reads from it to return the descriptive name, and validations confirm that a referenced expenditure type exists.
  • PA_IND_RATE_SCH_REVISIONS — The indirect rate schedule revisions table. Access to this table supports the checking logic that determines whether a cost base structure is referenced and therefore whether it can safely be altered or removed.

Usage Notes

PA_COST_BASE_EXP_TYPES_PKG is invoked indirectly through the Projects setup and maintenance forms, typically when a user defines or updates a cost base and associates expenditure types with it. It is not intended for direct invocation from SQL*Plus or custom PL/SQL, and it is not registered as a concurrent program entry point. The package is referenced by zero other packages in the ETRM catalog, confirming its role as a terminal validation utility whose callers are the setup forms and internal UI logic rather than other shared packages.

Because the package is classified as OTHER and is unsupported for extension, customizations should avoid calling these procedures directly. Instead, customers requiring equivalent validation should rely on the standard Projects setup forms or build their own validation logic against the underlying tables. As with all undocumented internal packages, signatures may change between point releases; any code that depends on them risks breakage during patching.