Search Results igc_cc_archive_purge_pkg




Overview
Explore in AI Chat

Overview

The APPS.IGC_CC_ARCHIVE_PURGE_PKG package is a PL/SQL archive and purge utility within the Oracle EBS Grants/Contracts (IGC) application family, specifically supporting the Contracts Core (CC) module. Its business function is to manage the lifecycle of Contracts Core transactional data by relocating eligible historical records into archive tables and subsequently removing them from the active operational tables, thereby controlling database growth while preserving an audit trail. The package operates on the principle of identifying candidate records that satisfy archiving criteria, copying them into dedicated archive structures, and then deleting or purging the source records once the archive has been validated. In the context of Oracle EBS 12.1.1 and 12.2.2, the package is classified as an OTHER API, meaning it is not a public interface intended for general external consumption but rather an internal maintenance utility. The package is registered in the APPS schema with a VALID status and depends on the SYS.STANDARD package, while also being referenced by itself, indicating internal recursive or shared logic.

Key Procedures and Functions

The package exposes four documented program units, each contributing to the archive and purge workflow:

  • ARCHIVE_PURGE_CC_REQUEST — The primary driver procedure. It orchestrates the end-to-end archive and purge operation for Contracts Core data, coordinating candidate identification, archive insertion, and purge execution.
  • GET_SOB_ID — A helper function that resolves the Set of Books identifier (or its GL Ledger equivalent in R12) associated with the records being processed, ensuring that archiving is scoped correctly by ledger.
  • GET_ORG_ID — A helper function returning the operating unit or organization identifier, used to partition the archive and purge activity by organizational context.
  • GET_LAST_ACTIVITY_DATE — A retrieval function that determines the most recent activity date for a given record or set of records, which is critical for evaluating whether a contract transaction qualifies as eligible for archival based on age thresholds.

These units collectively support a scoped, ledger- and organization-aware archival process. Parameter lists are not documented in the ETRM metadata and should not be assumed.

Tables Accessed

The package references a broad set of active and archive tables through APPS synonyms. On the source side, it reads from IGC_CC_ACCT_LINES, IGC_CC_ACCT_LINE_HISTORY, IGC_CC_ACTIONS, and payables-related tables AP_INVOICES_ALL and AP_INVOICE_DISTRIBUTIONS_ALL to gather the transactional and accounting detail subject to archival. It writes archived copies into parallel structures such as IGC_CC_ARC_ACCT_LINES, IGC_CC_ARC_ACCT_LINE_HIST, IGC_CC_ARC_ACTIONS, IGC_CC_ARC_DET_PF, and IGC_CC_ARC_DET_PF_HIST. Candidate eligibility is tracked in IGC_ARC_PUR_CANDIDATES, while IGC_CC_ARCHIVE_HISTORY and IGC_CC_ARCHIVE_HISTORY_ALL record the outcome of prior archive runs. Reference data is drawn from FND_APPLICATION and GL_LEDGERS to resolve application and ledger context. This dual-table pattern (active versus _ARC_ archive) is characteristic of Oracle's archive-and-purge architecture.

Usage Notes

Because the package is classified as OTHER and is referenced by zero other packages, it is not part of a public API surface and is not intended for direct invocation by custom code. It is typically invoked through an Oracle EBS concurrent program registered against the Contracts Core archive and purge process, scheduled during off-peak maintenance windows when historical contracts data has aged beyond the retention threshold defined by the enterprise. Administrators configure cut-off dates and organizational scope through the concurrent program parameters, which the internal procedures translate into the GET_SOB_ID, GET_ORG_ID, and GET_LAST_ACTIVITY_DATE lookups. Direct calls from forms are not documented. Sites performing custom archival should avoid bypassing the supported concurrent program, as improper invocation could compromise referential integrity between active and archive tables. The package behaves consistently across 12.1.1 and 12.2.2, with any ledger-related logic abstracted through the R12 GL_LEDGERS model.