Search Results baseline_budget




Overview

APPS.PA_BUDGET_WF is the workflow integration package for Oracle Projects budget approval processing in Oracle E-Business Suite 12.1.1 and 12.2.2. Its primary business function is to initiate, manage, and validate the Budget Approval workflow that governs whether a project budget or baseline budget can be submitted, approved, or rejected. The package acts as the bridge between the Oracle Projects budgeting subledger and the Oracle Workflow engine, ensuring that budget approval routing respects project-level and operating unit-level security and policy rules. The header comment identifies the source as PAWFBUVB.pls and records an API version constant, indicating the package conforms to a public API versioning convention used throughout Oracle Projects.

Key Procedures and Functions

The documented package exposes seven procedures and functions, each serving a distinct role in the budget approval lifecycle.

  • START_BUDGET_WF — Starts the Budget Approval workflow for a given budget version. Per the embedded comments, this wrapper is invoked directly from the Budgets form, from the public Baseline_Budget API, and from the Budget Integration Workflow. It calls PA_CLIENT_EXTN_BUDGET_WF.Start_Budget_Wf and PA_WORKFLOW_UTILS.Insert_WF_Processes. In Release 12 it is explicitly defined as a single project / operating unit workflow, requiring PA_BUDGET_UTILS.Set_Prj_Policy_Context to establish the correct OU context before any procedure call.
  • BASELINE_BUDGET — Responsible for the baseline budget operation, which formally establishes an approved budget as the project's baseline. This is the procedure most closely associated with the search term "baseline_budget." It operates in conjunction with the workflow and the baseline flag on the budget version.
  • SELECT_BUDGET_APPROVER — Determines or returns the appropriate approver for a budget, supporting the routing logic used during workflow initiation.
  • VERIFY_BUDGET_RULES — Validates whether the budget satisfies the configured approval rules before the workflow proceeds.
  • REJECT_BUDGET — Handles the rejection path of the approval cycle, updating budget status and workflow state accordingly.
  • BUDGET_WF_IS_USED — Returns whether the Budget Approval workflow is enabled for the applicable context, allowing callers to bypass workflow logic when it is not in use.
  • IS_FEDERAL_ENABLED — Indicates whether Federal-specific budgeting behavior is enabled, allowing conditional processing for public sector deployments.

Tables Accessed

The package reads from and writes to several core Oracle Projects and Workflow tables through APPS synonyms.

  • PA_BUDGET_VERSIONS — Stores budget version records, including baseline indicators and approval status, central to the BASELINE_BUDGET and REJECT_BUDGET logic.
  • PA_BUDGET_TYPES — Defines budget types applicable to a project, used in rule verification.
  • PA_PROJECTS and PA_PROJECTS_ALL — Supply project attributes; PA_PROJECTS_ALL is the MOAC-aware view of projects.
  • PA_PROJECT_TYPES — Provides project type classification used for rule and approver determination.
  • PA_WF_PROCESSES — Records workflow process instances associated with budgets.
  • WF_ITEM_ACTIVITY_STATUSES — Oracle Workflow activity status, queried to determine current workflow state.
  • FND_USER — Resolves approver and user identities during workflow routing.

Usage Notes

PA_BUDGET_WF is not typically called directly by end users. It is invoked from the Budgets form, from the public Baseline_Budget API, and from the Budget Integration Workflow. In MOAC-enabled 12.1.1 and 12.2.2 environments, any call into or out of the Budget Approval workflow must first invoke PA_BUDGET_UTILS.Set_Prj_Policy_Context so that the operating unit context matches the project being processed. Error messages surfaced through the form and public API use the 'PA_WF_CLIENT_EXTN' error code, passing the client extension name and error code as tokens. The package is referenced by four other packages, confirming its role as a shared workflow integration component. Customizations should avoid direct invocation of internal procedures and instead rely on the supported public API and client extension points.