Search Results igc_cc_arc_det_pf




Overview
Explore in AI Chat

Overview

IGC_CC_ARC_DET_PF is a table in the IGC (Contract Commitment) product of Oracle E-Business Suite, owned by the IGC schema. It stores detail payment forecast lines for contracts that are in the process of being archived. As its name implies — "IGC Contract Commitment Archive Detail Payment Forecast" — the table operates as a staging or archival repository that captures the granular, line-level composition of payment forecasts after the corresponding commitment contract records have been retired from active processing tables.

In the Contract Commitment architecture, payment forecasts represent the time-phased, monetary schedule against which a contract's obligations are recognized, billed, and encumbered. The archived detail table therefore preserves the exact distribution of forecasted amounts — entered, functional, billed, unbilled, and encumbered — so that historical contract audit trails, retrospective reporting, and statutory retention requirements can be satisfied without retaining the full live footprint of the contract.

From a modeling perspective, the supplied metadata classifies this object as satellite-leaning. This is a heuristic suggestion rather than a physical constraint: the table carries a surrogate primary key (ICADP_PK) and a dense set of descriptive, date-stamped, and amount-bearing attributes that characterize a business entity at a point in time. It also exhibits a self-referencing parent-child relationship, which gives the structure a hierarchical flavor uncommon in a pure satellite. Analysts designing a Data Vault representation should treat it as a satellite of a contract payment forecast hub, with the parent line relationship modeled as a same-hub link.

Key Information Stored

The table comprises 34 documented columns in the Oracle EBS 12.2.2 physical schema. The most operationally significant are:

Common Use Cases and Queries

The principal use case is historical pipeline and obligation reporting after a contract has been archived. A typical query reconstructs the archived forecast schedule for a contract by anchoring on the detail forecast line identifier and walking the hierarchy:

SELECT CC_DET_PF_LINE_ID, CC_DET_PF_LINE_NUM, PARENT_DET_PF_LINE_ID,
  CC_DET_PF_DATE, CC_DET_PF_ENTERED_AMT, CC_DET_PF_FUNC_AMT,
  CC_DET_PF_BILLED_AMT, CC_DET_PF_UNBILLED_AMT
FROM IGC.IGC_CC_ARC_DET_PF
WHERE CC_DET_PF_LINE_ID = :p_line_id
ORDER BY CC_DET_PF_LINE_NUM;

A second common pattern aggregates archived encumbrance exposure by forecast date, filtering on the encumbrance status column, to reconcile archived commitments against general ledger balances. A third pattern joins the archived distributed amount back to PO_DISTRIBUTIONS_ALL on the detail forecast line identifier to trace the original purchasing distribution that generated the commitment. Data-migration and purge scripts also query the table by creation and last-update dates to enforce retention policy windows.

Related Objects

The metadata documents a compact set of relationships:

  • IGC_CC_ARC_DET_PF (self-reference) — the PARENT_DET_PF_LINE_ID column points to the parent row in the same table, forming the forecast line hierarchy.
  • PO_DISTRIBUTIONS_ALL — joined via CC_DET_PF_LINE_ID, this links the archived forecast detail to the underlying purchasing distribution and is the most consequential external dependency.
  • IGC_CC_ARC_DET_PF.CC_ACCT_LINE_ID — the metadata records a foreign key reference for this column, tying each forecast line to its accounting line context.
  • Live payment forecast tables in the IGC schema — the archive table mirrors the structure of the active forecast detail, so the live counterpart is the natural sibling object for both extraction and restore operations.
  • IGC contract commitment APIs and concurrent programs that populate and purge this table — the archiving program inserts rows here, and reporting programs read from it once active rows are removed.

Because the FK targets for CC_ACCT_LINE_ID and the live forecast source are not fully enumerated in the supplied metadata, join designs should be validated against the actual IGC schema in the target release before being promoted to production.