Search Results parent_task_version_id




Overview
Explore in AI Chat

Overview

PA_STRUCT_TASK_WBS_V is a Projects (PA) module view owned by the APPS schema and defined over the core task and work breakdown structure tables of Oracle Projects. It presents the hierarchical task structure of a project alongside version, parent, scheduling, and financial attributes in a single flattened result set. Its primary role is to expose task-level WBS relationships — including the parent/child linkage between task versions — so that reporting, integration, and downstream processing can traverse the task hierarchy without directly joining the underlying element and version tables. The view is particularly relevant where the parent task version identifier is required, since it surfaces PARENT_TASK_VERSION_ID as a first-class column derived from the element version of each task.

Underlying Base Objects

The view is defined over the following documented base objects, all referenced through synonyms in the APPS schema:

The joins connect project to element, element to version, version to schedule (outer), and element to task (outer), yielding one row per task element version reflecting its position in the WBS.

Key Columns

Common Use Cases and Queries

Typical uses include reporting the WBS hierarchy for a project, identifying parent task versions for integration or migration, and validating task levels. A representative query for the parent task version column follows:

SELECT project_id,
       task_id,
       task_number,
       task_name,
       task_level,
       parent_task_id,
       parent_task_version_id,
       element_version_id
FROM   apps.pa_struct_task_wbs_v
WHERE  project_id = :p_project_id
ORDER  BY task_level, task_number;

To locate the children of a specific parent version:

SELECT task_number, task_name, element_version_id
FROM   apps.pa_struct_task_wbs_v
WHERE  parent_task_version_id = :p_parent_version_id;

Because the view resolves version-scoped hierarchy through the utility package, it is suited to reports that must distinguish structurally identical tasks across versions. Queries should filter on PROJECT_ID for performance, as the underlying joins span several large project element tables.