Search Results psbbv_budget_revision_position

Overview

PSBBV_BUDGET_REVISION_POSITION is a read-only view owned by the APPS schema within the Public Sector Budgeting (PSB) product module of Oracle E-Business Suite. It presents position-level budget revision data, exposing the individual revision records that have been applied against positions within a budget revision line. The view consolidates information from the position revision and revision line base tables into a single queryable structure, allowing reporting tools, concurrent programs, and custom integrations to retrieve revision details for a given budget revision, position, or budget group without navigating the underlying normalization directly.

The view is defined with the WITH READ ONLY clause, confirming that it is intended strictly for query and reporting purposes. Application logic that creates or modifies budget revision position data must operate against the base tables, while this view serves as the sanctioned read interface. Because the view is documented as VALID in the ETRM metadata for both 12.1.1 and 12.2.2, it can be treated as a stable object across those releases, though Oracle does not guarantee the stability of internal views for customer-developed code.

Underlying Base Objects

The view is defined over two Public Sector Budgeting base tables joined on the position line identifier:

• PSB_BUDGET_REVISION_POSITIONS (BRP) — supplies the position revision detail, including the revision position line identifier, position, budget group, effective dates, revision type, revision value type, revision value, and note identifier.
• PSB_BUDGET_REVISION_POS_LINES (BRL) — supplies the parent budget revision identifier associated with each position revision line.

The join condition is BRP.BUDGET_REVISION_POS_LINE_ID = BRL.BUDGET_REVISION_POS_LINE_ID, making the relationship a one-to-many association between revision position lines and their position-level revision records. The ETRM metadata records no additional referenced base objects beyond these two tables, and no PL/SQL functions or additional views are documented as participating in the definition.

Key Columns

• BUDGET_REVISION_ID — identifies the parent budget revision to which the position revision belongs; the primary grouping key for reporting by revision.
• BUDGET_REVISION_POS_LINE_ID — the revision position line identifier; the join key linking the two base tables.
• POSITION_ID — the position against which the revision is applied.
• BUDGET_GROUP_ID — the budget group context for the revision record.
• EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — the date range during which the revision record is effective, supporting date-effective reporting.
• REVISION_TYPE — categorizes the nature of the revision (for example, percentage or amount based).
• REVISION_VALUE_TYPE — qualifies how the revision value should be interpreted.
• REVISION_VALUE — the numeric value of the revision applied to the position.
• NOTE_ID — reference to an associated note or comment record.

Common Use Cases and Queries

Typical scenarios include auditing all position-level revisions within a budget revision, reconciling revision amounts by budget group, and feeding revision data into custom budget analysis reports. A representative query listing revisions for a specific budget revision is:

• SELECT budget_revision_id, position_id, budget_group_id, revision_type, revision_value_type, revision_value, effective_start_date, effective_end_date FROM apps.psbbv_budget_revision_position WHERE budget_revision_id = :p_revision_id ORDER BY position_id;
• Aggregation by budget group: SELECT budget_group_id, revision_type, SUM(revision_value) FROM apps.psbbv_budget_revision_position WHERE budget_revision_id = :p_revision_id GROUP BY budget_group_id, revision_type;
• Effective-dated filtering: SELECT position_id, revision_value FROM apps.psbbv_budget_revision_position WHERE SYSDATE BETWEEN effective_start_date AND effective_end_date;

Because the view is read-only, all such queries are safe for concurrent reporting use. Developers should confirm column semantics against the current PSB data model before embedding references in production customizations.