Search Results boundary_code

Overview

PA_BUDGETARY_CONTROL_OPTIONS_V is an Oracle EBS APPS view owned by the APPS schema in the Projects (PA) module. It exposes budgetary control configuration data used by Oracle Projects to determine how project budgets are validated, controlled, and integrated with Oracle General Ledger and encumbrance accounting. The view presents one row per budgetary control option record, giving reporting and integration processes a consolidated, read-only window into the rules that govern funds checking and budget enforcement for projects and project types.

In 12.1.1 and 12.2.2 the object retains the same definition and column set. Its role is primarily report-facing and integration-facing: external systems, custom reports, and extension logic that need to know the active budgetary control settings for a project or project type query the view rather than joining the base configuration table directly. The view also safeguards referential context by intersecting the options table with PA_IMPLEMENTATIONS on ORG_ID, ensuring only options belonging to an installed, active implementation are surfaced.

Underlying Base Objects

The view is defined over two synonyms, both resolving to APPS tables:

• PA_BUDGETARY_CONTROL_OPTIONS (OPT) — the primary source of all configuration columns in the view, including BOUNDARY_CODE, amount type, fund control levels, and budget type.
• PA_IMPLEMENTATIONS (IMP) — joined to filter the option rows by organizational implementation context.

The join predicate is:

NVL(OPT.PROJECT_TYPE_ORG_ID, -99) = NVL(IMP.ORG_ID, -99)

The NVL(..., -99) construct treats null organization identifiers as a common default bucket, so options without an explicit operating unit are matched to the corresponding null ORG_ID implementation. All columns of the view are pass-throughs from PA_BUDGETARY_CONTROL_OPTIONS; no aggregation or derivation occurs.

Key Columns

• BOUNDARY_CODE — identifies the budgetary control boundary (the level at which funds checking occurs, such as project, task, or resource). This is frequently the target of lookup queries.
• PROJECT_TYPE / PROJECT_ID — the project type or specific project to which the option applies.
• BALANCE_TYPE — the balance type on which budgetary control is based.
• BDGT_CNTRL_FLAG — indicates whether budgetary control is enabled for the record.
• AMOUNT_TYPE — the amount basis (for example, raw cost or burdened cost) used in control checks.
• FUND_CONTROL_LEVEL_PROJECT / _TASK / _RES_GRP / _RES — flags defining the granularity at which funds control is enforced across project, task, resource group, and resource.
• EXTERNAL_BUDGET_CODE, GL_BUDGET_VERSION_ID, ENCUMBRANCE_TYPE_ID — integration pointers to the external budget definition, the GL budget version, and the encumbrance type used for funds reservation.
• BUDGET_TYPE_CODE — the budget type to which the control option is tied.
• PROJECT_TYPE_ORG_ID — the organization identifier used in the implementation join.
• ROW_ID — the base row identifier, exposed for updatable or referenced access.
• Standard WHO columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The most common scenario is retrieving the boundary and control settings for a project type or project, particularly when diagnosing why a budget or expenditure is being blocked. The following query returns active control options with their boundary code:

SELECT PROJECT_TYPE, PROJECT_ID, BALANCE_TYPE, BOUNDARY_CODE,
BDGT_CNTRL_FLAG, AMOUNT_TYPE, BUDGET_TYPE_CODE
FROM APPS.PA_BUDGETARY_CONTROL_OPTIONS_V
WHERE BDGT_CNTRL_FLAG = 'Y';

A second scenario filters by boundary code to identify all projects or project types governed by a specific control boundary:

SELECT PROJECT_TYPE, PROJECT_ID, BOUNDARY_CODE,
FUND_CONTROL_LEVEL_PROJECT, FUND_CONTROL_LEVEL_TASK
FROM APPS.PA_BUDGETARY_CONTROL_OPTIONS_V
WHERE BOUNDARY_CODE = :p_boundary_code;

Integration routines also use the view to resolve the GL budget version and encumbrance type associated with a project so that encumbrance entries are posted to the correct ledger configuration. Because the view joins to PA_IMPLEMENTATIONS, only options valid for an installed implementation are returned, which prevents orphaned or obsolete configuration rows from appearing in downstream reports.