Search Results budget_pk




Overview
Explore in AI Chat

Overview

APPS.FII_PA_PABU_BUDGET_LCV is a reporting view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 environments, owned by the APPS schema. It belongs to the Oracle Projects (PA) reporting layer and specifically to the budgeting subject area delivered through the FII (Financial Intelligence) family of views. The abbreviation "LCV" denotes a "logical" or lightweight reporting view, and "PABU" references the Project Accounting Budget concept. The view exposes budget header information — identifiers, names, type, version, associated project, and status flags — for consumption by reporting tools, Oracle Business Intelligence applications, and integration interfaces that need a stable, denormalized projection of project budget data.

Because it surfaces a BUDGET_PK primary key column alongside descriptive attributes, the view is well suited as a lookup or dimension source for downstream joins against fact-style budget or expenditure records. It provides a simplified, read-only interface that shields consumers from the complexity of the underlying Projects budgeting schema.

Underlying Base Objects

The view is defined with a straightforward SELECT over a single documented base object, identified in the ETRM metadata as FIIBV_PA_PABU_BUDGET_LCV. The FIIBV_ prefix indicates a Financial Intelligence base view, which in Oracle Projects implementations typically resolves through a business view layer to the physical budget tables such as PA_BUDGET_VERSIONS and PA_PROJECTS. The projection is intentionally flat: it maps only the documented columns from the base object and pads the remainder of the select list with literal NULLs.

This NULL-padding pattern is characteristic of Oracle's FII extensibility design, where a fixed column signature is maintained so that downstream reporting tools and BI repositories can depend on a consistent shape even when not all attributes are populated. The metadata notes that no additional base objects are documented, indicating the view is a thin pass-through rather than a layered join.

Key Columns

  • BUDGET_PK — The primary key of the budget record. This is the most frequently referenced column and the object of the user's search term; it uniquely identifies a budget and serves as the join key to related facts and dimensions.
  • NAME — The descriptive name assigned to the budget.
  • BUDGET_TYPE — Classifies the budget (for example, approved cost budget or revenue budget), distinguishing the purpose of the record.
  • VERSION_NAME — The budget version label, used to separate successive iterations of a budget for the same project.
  • PROJECT_NAME — The name of the project to which the budget belongs, enabling direct reporting without an additional join.
  • CURRENT_FLAG — Indicates whether the budget version is the current version for its type.
  • ORIGINAL_FLAG — Indicates whether the record is the original (baseline) budget.
  • CURRENT_ORIGINAL_FLAG — Distinguishes the budget that is simultaneously current and original.
  • INSTANCE — Identifies the source application instance, supporting multi-instance and consolidated reporting.
  • LAST_UPDATE_DATE — The audit timestamp of the most recent modification, useful for incremental extraction.

Common Use Cases and Queries

The view supports budget reporting, BI extraction, and integration staging. A typical query retrieves current budgets for a given project:

  • SELECT budget_pk, name, budget_type, version_name, project_name FROM apps.fii_pa_pabu_budget_lcv WHERE current_flag = 'Y';
  • SELECT budget_pk, project_name, version_name FROM apps.fii_pa_pabu_budget_lcv WHERE original_flag = 'Y' ORDER BY project_name;
  • SELECT budget_pk, last_update_date FROM apps.fii_pa_pabu_budget_lcv WHERE last_update_date >= :since_date;

Common scenarios include resolving a budget_pk to a human-readable project and version before joining to budget line facts, selecting the original versus current version for variance analysis, and incrementally extracting changed budget headers by timestamp. Because the view is read-only and lives in the APPS schema, access should be granted through the appropriate responsibility and, in 12.2.2, through the editioned APPS synonym layer.