Search Results igc_cc_headers

Overview

The IGC_CC_HEADERS table is the central repository for the financial representation of a contract within the Oracle E-Business Suite Contract Commitment (IGC) module. It serves as the master header record for a contract commitment, which is a financial instrument used to track and control obligations and expenditures against contracts before they become formal purchase orders or invoices. Its primary role is to store general, high-level information about the contract, linking it to key entities such as vendors, sets of books, and users, thereby establishing the financial and organizational context for all subsequent commitment lines and transactions.

Key Information Stored

The table's structure is defined by its primary and foreign keys, which reveal the critical data points it manages. The primary key, CC_HEADER_ID, uniquely identifies each contract commitment record. Essential foreign key relationships indicate the table stores the contract's currency (CURRENCY_CODE), its associated ledger (SET_OF_BOOKS_ID), and the involved trading partner via VENDOR_ID, VENDOR_SITE_ID, and VENDOR_CONTACT_ID. It also tracks the personnel lifecycle through user IDs for the owner (CC_OWNER_USER_ID), preparer (CC_PREPARER_USER_ID), and current user (CC_CURRENT_USER_ID). The PARENT_HEADER_ID column supports hierarchical contract structures, allowing commitments to be linked to parent agreements. The linkage to PO_HEADERS_ALL via CC_HEADER_ID is crucial for tracking the formal purchase order created from the commitment.

Common Use Cases and Queries

This table is fundamental for reporting and auditing contract commitments. Common use cases include generating a summary report of all commitments for a specific vendor or ledger, analyzing the commitment lifecycle by user, and reconciling commitments to their resulting purchase orders. A typical query might join IGC_CC_HEADERS to PO_HEADERS_ALL to find commitments that have not yet been converted to POs, or to FND_USER tables to list commitments by owner. For example:

• SELECT cc.CC_HEADER_ID, cc.CONTRACT_NUM, p.SEGMENT1 PO_NUMBER FROM IGC_CC_HEADERS cc LEFT JOIN PO_HEADERS_ALL p ON cc.CC_HEADER_ID = p.CC_HEADER_ID WHERE p.PO_HEADER_ID IS NULL;
• SELECT cc.CC_HEADER_ID, usr.USER_NAME OWNER FROM IGC_CC_HEADERS cc, FND_USER usr WHERE cc.CC_OWNER_USER_ID = usr.USER_ID AND cc.SET_OF_BOOKS_ID = :ledger_id;

Data from this table also feeds into the IGC_CC_PROCESS_DATA and IGC_CC_PROCESS_EXCEPTIONS tables for budgetary control and compliance workflows.

Related Objects

The IGC_CC_HEADERS table has extensive relationships within the EBS architecture. It is the parent table for detailed commitment lines and transactional data. Key dependent objects include IGC_CC_PROCESS_DATA and IGC_CC_PROCESS_EXCEPTIONS, which store control processing information. It also relates to the interface table IGC_CC_ACCT_LINES_INTERFACE. Crucially, it integrates with core EBS modules: Financials via GL_SETS_OF_BOOKS and FND_CURRENCIES, Purchasing via PO_HEADERS_ALL, PO_VENDORS, and related vendor tables, and Human Resources via HR_LOCATIONS_ALL. The recursive foreign key on PARENT_HEADER_ID indicates a self-referential relationship for hierarchical commitments. The metadata note "Not implemented in this database" suggests the table may be part of a product family not installed in the specific instance being documented.