Search Results set_current_project_id

Overview

GMS_BURDEN_COSTING is an Oracle EBS PL/SQL package owned by the APPS schema that encapsulates the burden cost accounting logic used by Oracle Grants Management (GMS) and its integration with Oracle Projects. Burden costing represents the indirect costs — fringe, overhead, and material handling — that are applied on top of raw expenditure items to arrive at fully burdened costs for sponsored projects and awards. The package is classified as OTHER in the ETRM inventory, indicating that it is an internal utility package rather than a public, versioned API intended for direct third-party extension.

Its primary design role is to hold session-scoped state for burden cost processing. Rather than passing a project identifier through every call in a burden calculation chain, the package stores the current project_id in a package-level variable that other procedures within the burden costing flow can read on demand. This pattern is common in EBS cost allocation and accounting code, where a single logical transaction may touch many private procedures that must all operate against the same project context.

Key Procedures and Functions

The documented interface is deliberately narrow, consisting of two entry points:

• SET_CURRENT_PROJECT_ID — Updates the current project_id held in the package variable. It is declared with a PRAGMA RESTRICT_REFERENCES setting of WNDS (Write No Database State), confirming that the procedure performs no DML and only mutates package memory rather than database tables.
• GET_CURRENT_PROJECT_ID — Returns the currently cached project identifier as a NUMBER. It carries the stronger purity declaration WNDS, WNPS (Write No Database State, Write No Package State), meaning it is a read-only accessor that neither modifies database state nor the package's own variables.

Together the two routines implement a simple setter/getter contract. No parameter lists beyond the single input for the setter and no return value beyond the project id for the getter are documented, and no other public procedures are exposed by the package specification.

Tables Accessed

Per the documented metadata, the package references PA_PROJECTS_ALL through an APPS synonym. In Oracle Projects, PA_PROJECTS_ALL is the central repository of project definitions, including project numbers, names, organization assignments, and project status. Because the purity pragmas on both documented routines are WNDS, the base package specification itself performs no direct DML against this table; the project identifier that is cached would typically be validated or derived elsewhere in the burden costing flow where PA_PROJECTS_ALL is queried. The reference to PA_PROJECTS_ALL therefore establishes the package's dependency on core Projects data rather than implying that these two procedures write to it.

Usage Notes

GMS_BURDEN_COSTING is invoked in the context of burden cost accounting for grants and sponsored projects, most often from internal Oracle Projects and Grants costing engines rather than from end-user forms directly. The metadata notes that the package is referenced by one other package, which suggests it is called from a higher-level driver — likely a burden calculation or cost distribution routine — that first calls SET_CURRENT_PROJECT_ID to establish context and subsequently calls GET_CURRENT_PROJECT_ID as it processes expenditure items belonging to that project.

Because the package holds state in package variables, callers must be aware that the cached value persists for the duration of the database session. Custom code that invokes these routines should set the project id before each logical unit of burden calculation and should not assume the value survives a session reset or persists across unrelated processing. The WNDS and WNPS pragmas make both routines safe to call from SQL contexts and from code subject to purity restrictions, such as function-based indexes and certain trigger scenarios. Given its OTHER classification, the package should be treated as an internal implementation detail of GMS burden costing; extensions should preferably wrap rather than modify it, and any direct dependency should be re-verified during upgrades between 12.1.1 and 12.2.2, since the header indicates the specification has been stable since Release 12.0.