Search Results get_budget_type_code

Overview

PA_BUDGET_UPGRADE_PKG is a PL/SQL package in the Oracle E-Business Suite Projects (PA) module, owned by the APPS schema and declared with AUTHID CURRENT_USER. Its source header (PAXBUUPS.pls, version 120.1, dated 2005) indicates that the package was created to support data upgrade and setup-processing operations associated with project budgets. In the context of Oracle EBS 12.1.1 and 12.2.2, the package behaves as a specialized upgrade utility rather than a general-purpose budgeting API. It is classified under ETRM as an "OTHER" API type, meaning Oracle does not expose it as a public, supported extension interface. Instead, it is invoked internally to initialize budget-related setup data and to process project records across a range of project identifiers. The package maintains a substantial set of package-level global variables — including budget type, version number, budget status, current/original flags, and audit columns such as created-by, last-updated-by, and last-update-login — which are populated from FND_GLOBAL during execution. These globals allow the upgrade routines to carry context between the individual procedures without repeated lookups.

Key Procedures and Functions

• GET_PROJECT_ID — A function that derives and returns the project identifier currently in scope for the upgrade process. It is declared with PRAGMA RESTRICT_REFERENCES (WNDS, WNPS), confirming that it performs no database writes and reads no package state.
• GET_BUDGET_TYPE_CODE — A function that derives and returns the budget type code applicable to the project being processed. Like GET_PROJECT_ID, it is constrained by PRAGMA RESTRICT_REFERENCES (WNDS, WNPS) and populates the g_budget_type_code global. This is the routine most commonly searched by developers investigating budget type resolution logic.
• INITIALIZE — A procedure that accepts the standard EBS error-handling parameters (x_err_code, x_err_stage, x_err_stack, passed as NOCOPY per File.Sql.39, bug 4440895). It prepares the package globals and working state required before the main upgrade steps execute.
• CREATE_SETUP_DATA — A procedure that creates the setup data needed by the upgrade, using the same error-handling signature. It likely populates or normalizes records associated with resource lists and budget setup.
• MAIN — The primary driver procedure. It accepts a minimum and maximum project identifier (x_min_project_id, x_max_project_id) so that processing can be restricted to a defined range of projects, together with the standard error-handling parameters. This range-based design supports restartable, chunked execution.

Tables Accessed

The package references two documented tables through APPS synonyms:

• PA_RESOURCES — The resource definition table. The package declares a global record (g_uncla_rec) based on this table's ROWTYPE, indicating it reads resource rows during setup and budget upgrade processing.
• PA_RESOURCE_LIST_MEMBERS — The table linking resources to resource lists. A global record (g_uncat_rec) is declared with this table's ROWTYPE, and in-memory collections (g_cat_rec) are built from resource list member data.

These accesses are consistent with an upgrade that must reconcile resource lists, their members, and associated budget structures for projects in the specified ID range.

Usage Notes

PA_BUDGET_UPGRADE_PKG is not a supported public API. It is not referenced by any other documented package, and its version header carries the "noship" designation, meaning Oracle did not ship it as an externally callable component in the standard product. It is typically invoked by internal upgrade or data-fix scripts and, in some cases, by concurrent programs or diagnostic routines that need to process budget setup data across a project range. Because MAIN requires explicit minimum and maximum project IDs, callers must determine the appropriate range themselves and invoke the package repeatedly to cover all projects. Custom code should avoid depending on this package directly; any requirement to resolve project ID or budget type code should be met through supported Projects APIs or views. When error handling is required, the caller must supply and inspect x_err_code, x_err_stage, and x_err_stack, since the package reports failures through these OUT parameters rather than raising exceptions.