Search Results pa_purge




Overview

PA_PURGE is a core Oracle Projects utility package in the APPS schema that provides the runtime engine for permanently removing project-related data from the Oracle E-Business Suite database. Its principal business function is to support the Project Purge feature within Oracle Projects, which allows organizations to reclaim storage, satisfy data-retention policies, and archive obsolete projects by physically deleting the transactional and descriptive records associated with a project once it is no longer operationally required. In Oracle EBS 12.1.1 and 12.2.2, purge is a destructive, one-way operation, so PA_PURGE acts as an orchestration layer that validates purge eligibility, drives the batch process that tracks the purge, and coordinates the deletion of detail, summary, billing, costing, capital, inter-company, and project-definition data. The package is classified as OTHER in the ETRM metadata because it is primarily an internal, module-owned API rather than a published integration interface. Its status is VALID, and it is not referenced by any other database object, confirming that it is invoked directly by Oracle Projects applications rather than being called programmatically by dependent code.

Key Procedures and Functions

The documented interface of PA_PURGE consists of four procedures and functions:

  • PURGE — The top-level driver entry point that initiates purging for a project or purge batch. It establishes the purge context, invokes the subordinate purge modules for each data category, and commits the overall operation.
  • PURGE_PROJECT — Performs the purge of an individual project, coordinating the removal of that project's detail records through the associated purge sub-packages.
  • COMMITPROCESS — Handles the commit and checkpoint logic for the purge run. Because purging can involve very large volumes of rows, work is committed in controlled units rather than in a single transaction.
  • GET_POST_PURGE_STATUS — Returns the status of a project or purge batch after purge processing has completed, allowing callers to determine whether the operation succeeded and whether residual records remain.

No parameter lists are documented in the ETRM metadata, and none are asserted here.

Tables Accessed

PA_PURGE and its dependencies reference the following documented APPS tables:

  • PA_IMPLEMENTATIONS — Supplies the Oracle Projects implementation and business-group context under which purge processing runs.
  • PA_PROJECTS_ALL — The master project table, read to identify the project being purged and its associated attributes.
  • PA_PROJECT_TYPES_ALL — Provides project type definitions used to determine purge behavior and eligibility.
  • PA_PURGE_BATCHES — The controlling table for purge batches; PA_PURGE reads and updates this table to track batch progress and outcome.
  • PA_PURGE_PRJ_DETAILS — Stores the purge detail rows that record which components of each project have been processed.
  • PA_PURGE_PROJECTS — Records the projects submitted for purge and their processing status.

The dependency metadata additionally shows PA_PURGE invoking the sub-packages PA_PURGE_BILLING, PA_PURGE_CAPITAL, PA_PURGE_COSTING, PA_PURGE_EXTN, PA_PURGE_ICIP, PA_PURGE_PJR_TXNS, PA_PURGE_PRJ_DETAILS, PA_PURGE_PROJECTS, and PA_PURGE_SUMMARY, along with utilities including PA_DEBUG, PA_UTILS2, and PA_PROJECT_UTILS2, plus FND_GLOBAL for session context and GL_ALC_LEDGER_RSHIPS_V for ledger relationships.

Usage Notes

PA_PURGE is normally invoked indirectly through the Oracle Projects Purge concurrent program or the Project Purge windows in Oracle Projects, where the user selects and submits projects for purge. It should not be called ad hoc from SQL*Plus against a production instance. Custom code that needs purge behavior should be modeled on the standard concurrent program flow rather than calling PURGE directly, since the package assumes Oracle Projects session initialization and the presence of valid PA_PURGE_PROJECTS and PA_PURGE_BATCHES control rows. Because purge permanently deletes financial and project data and cascades across multiple sub-packages, procedures should be exercised first in a cloned or test environment, and standard backup and retention procedures must be completed before execution. The COMMITPROCESS and GET_POST_PURGE_STATUS routines exist specifically to support long-running batch runs, so monitoring of purge batches through the standard Oracle Projects purge status views is recommended.