Search Results task_status_rollup

Overview

APPS.PA_STRUCT_TASK_ROLLUP_PUB is a public PL/SQL package in Oracle E-Business Suite used by Oracle Projects (PA) to perform structural task and status rollup processing across a project workplan hierarchy. Within Oracle Projects, project structures are composed of tasks and subprojects arranged in a parent-child relationship. The rollup engine consolidates information from lower-level structure elements up through parent elements, propagating schedule dates, status values, and rollup attributes so that summary-level tasks consistently reflect the state of their children. The package is declared with AUTHID DEFINER, meaning it executes with the privileges of its owner (APPS) rather than the calling user, and it exposes a formal public API surface intended for reuse by other Oracle Projects components, forms, and custom extensions.

The package metadata indicates that it is referenced by five other packages, confirming its role as a shared utility in the Oracle Projects workplan and structure processing stack. Because the caller module parameter defaults to SELF_SERVICE, the API is frequently invoked in contexts associated with self-service project management and workplan maintenance flows.

Key Procedures and Functions

The ETRM documentation records six procedures for this package:

• TASKS_ROLLUP_UNLIMITED — Performs task rollup for a set of project element versions supplied as a PL/SQL collection indexed by BINARY_INTEGER. It supports an unlimited number of element versions, making it suitable for large workplans where the bounded variant would be insufficient. Standard API control parameters include API version, message list initialization, commit control, validate-only mode, validation level, calling module, debug mode, and maximum message count, with return status, message count, and message data as outputs.
• TASKS_ROLLUP — Performs task rollup for a bounded collection of element versions (PA_NUM_1000_NUM), providing the same API control signature as the unlimited variant. It is appropriate when the number of element versions to process falls within the fixed collection size.
• TASK_STATUS_ROLLUP — Rolls up task status values through the structure hierarchy using a structure version identifier, causing parent tasks to reflect the aggregate or derived status of their descendant tasks.
• TASK_STAT_PUSHDOWN_ROLLUP — Combines status pushdown with rollup behavior, propagating status information downward as well as upward within the structure so that dependent elements remain synchronized.
• ROLLUP_FROM_SUBPROJECT — Handles rollup originating from subproject boundaries, consolidating data across subproject structures into their parent project structures.
• PROGRAM_SCHEDULE_DATES_ROLLUP — Rolls up schedule dates across the structure hierarchy, ensuring that parent-level dates reflect the earliest start and latest finish of subordinate elements.

Tables Accessed

The package operates against the core Oracle Projects structure tables accessed through APPS synonyms:

• PA_PROJ_ELEMENTS and PA_PROJ_ELEMENT_VERSIONS — store project element definitions and their versioned instances; these are the primary inputs to rollup processing.
• PA_PROJ_ELEM_VER_STRUCTURE and PA_PROJ_ELEM_VER_SCHEDULE — hold the hierarchical relationships and schedule data that rollup processing aggregates.
• PA_PROJ_STRUCTURE_TYPES — defines the structure types governing which rollup rules apply.
• PA_PROJ_WORKPLAN_ATTR — stores workplan attributes affected by status and date rollup.
• PA_PROJECTS_ALL, PA_PROJECT_STATUSES, and PA_OBJECT_RELATIONSHIPS — provide project-level context and object relationship metadata.
• PLITBLM — the PL/SQL message table used by the FND message stack for error and warning reporting.

Usage Notes

PA_STRUCT_TASK_ROLLUP_PUB is typically invoked from Oracle Projects self-service workplan forms and concurrent programs, and from other Oracle Projects packages handling structure maintenance. Custom code should call the public procedures using the standard API pattern: initialize the message list, set p_validate_only to G_TRUE to preview effects before committing, then pass p_commit as G_TRUE only when the rollup should be persisted. Callers should always inspect x_return_status and drain messages via x_msg_count and x_msg_data. Because the package executes AUTHID DEFINER, grants on the package rather than on underlying tables govern execution privileges.