Search Results pa_project_sets_pub




Overview

PA_PROJECT_SETS_PUB is the public, published API package for maintaining project sets within Oracle Projects in Oracle E-Business Suite 12.1.1 and 12.2.2. A project set is a named, reusable grouping of projects and project ranges that drives reporting, summarization, costing, and cross-project inquiry throughout the Oracle Projects suite. The package body owns the business logic that validates and persists these groupings while hiding the underlying private implementation from external callers.

The package is registered in the APPS schema with a VALID status and is classified as a PUB (public) API in ETRM, meaning Oracle supports its invocation by external code. It is not referenced by any other database object, confirming its role as a top-level entry point rather than an internal dependency. Two other packages reference it, indicating some internal reuse by Oracle-delivered code. The body delegates validation, message handling, and profile lookups to FND_API, FND_MSG_PUB, FND_PROFILE, PA_DEBUG, PA_INTERFACE_UTILS_PUB, and the private worker package PA_PROJECT_SETS_PVT, and it also touches HZ_UTILITY_PUB and HZ_PARTIES for party-related processing.

Key Procedures and Functions

The documented API surface consists of six procedures and functions:

  • CREATE_PROJECT_SET — Creates a new project set header, establishing the set name, description, and organizational context. The set may optionally be created with an initial set of member lines in a single call.
  • UPDATE_PROJECT_SET — Modifies attributes of an existing project set header, such as its name or description. The identifier of the set must reference a valid, existing record.
  • DELETE_PROJECT_SET — Removes a project set header and its associated lines. This is the logical inverse of CREATE_PROJECT_SET and is typically guarded by business rules preventing deletion of sets still in use.
  • CREATE_PROJECT_SET_LINE — Adds a single project or project-range line to an existing project set. Each line defines a member project, and the collective set of lines determines the population the set resolves to.
  • DELETE_PROJECT_SET_LINE — Removes a single line from a project set without affecting the set header or other members.
  • PARTY_MERGE — Handles the impact of a Trading Community Architecture (TCA) party merge on project sets. Because project sets can be party- or customer-based, merging duplicate parties in TCA requires remediation of any affected sets and lines to preserve referential integrity.

These procedures expose only the purpose and effect of the API; parameter lists are deliberately not enumerated here and should be taken from the package specification or Oracle documentation.

Tables Accessed

The body reads and writes the following documented tables through APPS synonyms:

  • PA_PROJECT_SETS_B — The base table storing project set header records (name, description, and other set-level attributes).
  • PA_PROJECT_SETS_TL — The translation table holding language-dependent set names and descriptions, enabling multilingual support.
  • PA_PROJECT_SET_LINES — Stores the individual member lines that map projects (and project ranges) into a given set.
  • HZ_PARTIES — The TCA party table accessed during PARTY_MERGE processing to reconcile party-based set definitions after a merge.

The package also depends on PA_PROJECT_SETS_PUB (its specification) and PA_PROJECT_SETS_PVT for the underlying private logic.

Usage Notes

PA_PROJECT_SETS_PUB is normally invoked from the Oracle Projects forms (Project Sets windows) and from concurrent programs that generate, copy, or duplicate project sets. In 12.1.1 and 12.2.2, the same public interface is used by the TCA party merge concurrent process to call PARTY_MERGE when customer or party records are merged. Because it is a PUB API, custom code can call it to script bulk creation of project sets or lines, provided the standard FND_API conventions are observed: the caller must initialize fnd_global.apps_initialize, inspect the returned x_return_status, and retrieve errors from the FND message stack. Direct INSERT, UPDATE, or DELETE statements against the underlying tables should be avoided, since the API enforces validation, translation handling, and profile-based security that ad-hoc DML would bypass.