Search Results pa_fp_view_adj_v




Overview
Explore in AI Chat

Overview

PA_FP_VIEW_ADJ_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, belonging to the Projects (PA) product family. It presents adjusted financial plan amounts broken down by accounting period, consolidated across all adjustment reason codes defined in the system. The view is part of the Project Financial Planning (FP) reporting layer and is intended to expose budget or forecast version data that has been modified by adjustments — for example, when a planner reallocates or corrects an approved financial plan amount and records a reason for the change.

Because the view is filtered dynamically by the global package PA_FIN_PLAN_VIEW_GLOBAL, it is not a static snapshot of data. Instead, it returns rows for the budget version and amount type currently set in the global planning context, which makes it suitable as a source for concurrent-program reports, discoverer worksheets, or BLITZ/BI Publisher extracts that need to show adjustment activity alongside the reason descriptions users recognize.

Underlying Base Objects

The view is defined over the following documented base objects:

  • PA_FP_ADJ_ELEMENTS (synonym to the adjustment element table/entity) — supplies the adjustment_reason_code and adjustment element identity.
  • PA_FP_PERIOD_VALUES_V — supplies the per-period amounts (period_amount1 through period_amount13) and the preceding/succeeding period amounts.
  • PA_RESOURCE_ASSIGNMENTS — restricts the result set to adjustment elements tied to an OWN resource assignment.
  • PA_AMOUNT_TYPES_VL — provides the amount type/subtype join used to filter by the currently selected amount type.
  • PA_LOOKUPS — translates the stored adjustment_reason_code into the user-facing adjustment_reason_name.
  • PA_FIN_PLAN_VIEW_GLOBAL (package) — supplies the runtime context: GET_VERSION_ID() and GET_AMOUNT_TYPE_CODE().

The joins are driven by budget_version_id and resource_assignment_id, and the period values are linked through object_id = adj_element_id with object_type_code fixed to 'ADJ_ELEMENTS'.

Key Columns

  • adjustment_reason_code — the stored lookup code identifying the reason for the adjustment; this is the column that users search on when tracing why a plan was changed.
  • adjustment_reason_name — the meaning of that code, sourced from PA_LOOKUPS, suitable for display in reports.
  • preceding_periods_amount / succeeding_periods_amount — amounts attributed to periods adjacent to the reporting window, shown only where non-zero via NVL wrappers.
  • period_amount1 … period_amount13 — the period-by-period adjusted amounts; each is NVL-guarded to zero so that summed output remains arithmetically correct.
  • total_pa — the sum of period_amount1 through period_amount13, representing the full plan value across the displayed periods.
  • total — the sum of period_amount1 through period_amount6, a partial total typically corresponding to the current planning year or the first six displayed periods.

Common Use Cases and Queries

A typical use case is auditing adjustments by reason. Because the version and amount type are resolved from the package, the caller must first set the planning context (as the Financial Planning screens do) before the view returns meaningful rows:

  • Reporting all adjustment reasons applied to the current version.
  • Comparing adjusted totals (total_pa) against the base plan to determine adjustment impact.
  • Driving multi-period trend analyses by reason code.
SELECT adjustment_reason_code,
       adjustment_reason_name,
       total_pa,
       total
FROM   apps.pa_fp_view_adj_v
ORDER  BY adjustment_reason_name;

Filtering by a specific reason, for example retirement or reallocation, can be done on the code column:

SELECT adjustment_reason_code,
       SUM(total_pa) AS adjusted_total
FROM   apps.pa_fp_view_adj_v
WHERE  adjustment_reason_code = :reason_code
GROUP  BY adjustment_reason_code;

Because the view depends on PA_FIN_PLAN_VIEW_GLOBAL state, queries executed outside the planning UI may return no rows unless the context is initialized. This behavior should be accounted for in custom reports and concurrent programs that consume the view.