Search Results incremental_work_qty




Overview
Explore in AI Chat

Overview

PA_CURR_PROJ_TASK_PROG_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, belonging to the Projects (PA) product family. Its purpose is to expose the current, published percent-complete progress records for project tasks and other project elements, enriched with project status information, rollup work quantities, and the identity of the party that published the progress entry. The view is read-only and is typically consumed by reporting tools, dashboards, Oracle Business Intelligence extracts, and interface programs that need a denormalized, ready-to-query snapshot of task progress rather than joining the underlying PA tables individually.

The "CURR" in the name reflects two hard-coded filters embedded in the view definition: only rows where PUBLISHED_FLAG = 'Y' and CURRENT_FLAG = 'Y' are returned. This means the view always resolves to the latest published progress version for each object, eliminating historical or draft rows. The view is valid and marked as an APPS-owned synonym-based reporting object in ETRM 12.1.1 and 12.2.2.

Underlying Base Objects

The view is defined over four referenced base objects, all accessed through APPS synonyms:

The join logic enforces that only published, current percent-complete rows with a corresponding rollup record on the same computed date are surfaced.

Key Columns

Common Use Cases and Queries

Typical scenarios include project progress dashboards, incremental-vs-cumulative work reporting, and identifying the latest publisher of progress for a task. A representative query retrieving incremental work quantities per task is:

  • SELECT project_id, task_id, as_of_date, incremental_work_qty, cumulative_work_qty, estimated_remaining_effort FROM pa_curr_proj_task_prog_v WHERE project_id = :p_project_id;
  • SELECT project_id, task_id, completed_percentage, published_by_name, progress_comment FROM pa_curr_proj_task_prog_v WHERE as_of_date = TRUNC(SYSDATE);

Because the view already filters for published and current records and joins the rollup, no additional joins against PA tables are required, making it well suited to ad-hoc reporting and downstream extraction.