Search Results igc_cc_header_history




Overview
Explore in AI Chat

Overview

The IGC_CC_HEADER_HISTORY table belongs to the IGC (Contract Commitment) product family within Oracle E-Business Suite and serves as the persistent store of contract versions. In ETRM and related contract commitment flows, a single contract header may be revised, amended, or renegotiated multiple times over its lifecycle. Rather than overwriting the prior state of the header, the application preserves each historical revision as a distinct row in this table, keyed by the combination of the contract header identifier and a version number. This design enables version-to-version comparison, audit reconstruction of contract terms at a point in time, and traceability between commitment activity and the exact header revision that governed it.

The heuristic Data Vault classification derived from the documented foreign-key structure is satellite-leaning. This suggests the object is best modeled as a satellite attached to a contract header hub (or a version link), where CC_HEADER_ID provides the parent reference and CC_VERSION_NUM supplies the change/sequence context that distinguishes one descriptive snapshot from another. Treated purely as a reference, the table functions as a temporal extension of the current header, capturing attribute values as they stood at each revision.

The ETRM metadata explicitly records that this table is not implemented in the reference database, meaning the documented structure represents the intended or historical data model rather than a deployed physical object in that environment. Analysts should confirm physical existence and column layout against the target instance before relying on it in extraction logic.

Key Information Stored

The documented metadata identifies a composite primary key, IGC_CCHH_PK, defined over two columns, which together provide the unique identity of each contract version record:

  • CC_HEADER_ID — the parent contract header identifier; the business-key candidate linking the version back to the owning header and acting as the first component of the primary key.
  • CC_VERSION_NUM — the version or revision sequence number; the second primary-key component that orders and distinguishes successive snapshots of the same header. In combination with CC_HEADER_ID it forms the unique business key (unique index candidate) for each historical revision.

Beyond the key columns, the table carries the descriptive header attributes that are preserved per version — contractual terms, status, amounts, dates, and other commitment-related fields inherited from the live header structure. Because the ETRM excerpt enumerates only the key columns and foreign-key relationships, the remaining attribute set should be verified directly from the database. The foreign-key relationship documented for this object is self-referential: IGC_CC_HEADER_HISTORY.CC_HEADER_ID is shown as referencing IGC_CC_HEADER_HISTORY.CC_HEADER_ID, reflecting the parent-child nature of the header-to-version relationship within the model.

Common Use Cases and Queries

Typical uses center on as-of reporting, amendment auditing, and version trend analysis. A representative query to retrieve the latest revision of each contract header:

  • SELECT h.* FROM IGC_CC_HEADER_HISTORY h WHERE h.CC_VERSION_NUM = (SELECT MAX(x.CC_VERSION_NUM) FROM IGC_CC_HEADER_HISTORY x WHERE x.CC_HEADER_ID = h.CC_HEADER_ID);
  • SELECT COUNT(*) FROM IGC_CC_HEADER_HISTORY WHERE CC_HEADER_ID = :p_header_id; — to measure how many times a contract has been amended.
  • Joining to the current header on CC_HEADER_ID to compare the active record against any prior CC_VERSION_NUM, supporting change-detection and audit reports.

Reporting scenarios include reconstructing contract terms as of a reporting date, isolating headers with frequent renegotiation, and reconciling commitment balances to the governing version. Because the table is documented as not implemented in the reference database, queries must be validated against the actual instance.

Related Objects

The most significant relationships flow through the documented key and foreign-key columns:

  • IGC_CC_HEADER_HISTORY (self) — joined via CC_HEADER_ID; models the parent/version hierarchy and the documented single FK relationship.
  • Current contract header table — the live IGC contract header, joined on CC_HEADER_ID, providing the present-version counterpart to each archived revision.
  • Downstream contract line, commitment, and transaction entities that carry CC_HEADER_ID and resolve to a specific CC_VERSION_NUM.
  • Reporting views and concurrent programs within the IGC module that reconstruct historical contract state.

Because the ETRM documentation is limited and states the table is not implemented, all related-object joins should be confirmed against the target EBS 12.1.1 or 12.2.2 instance.