Search Results igc_cca_pk

Overview

IGC_CC_ACTIONS is a transactional table in the IGC (Contract Commitment) product module of Oracle E-Business Suite, available in both 12.1.1 and 12.2.2. As its ETRM description states, the table records "actions performed against contracts." Each row captures a discrete activity — such as an approval, amendment, termination, or workflow-driven event — associated with a specific contract header. The table therefore functions as an activity or audit log layered on top of the contract master, enabling users to trace the lifecycle of actions applied to a contract over time.

From a data modeling perspective, the mined heuristic classification of IGC_CC_ACTIONS is satellite-leaning. This suggests the table is best modeled as a satellite surrounding a contract hub (most likely IGC_CC_HEADERS keyed on CC_HEADER_ID), holding descriptive, time-varying attributes about actions rather than acting as the contract entity itself. The classification is a modeling suggestion derived from the foreign-key structure, not a mandated physical design.

Key Information Stored

The documented schema comprises 13 columns in the IGC schema. The most significant are:

• CC_HEADER_ID — Foreign key to the parent contract header. It identifies which contract the action pertains to and forms the leading component of the primary key.
• CC_ACTION_NUM — Sequence number of the action within a contract; the second component of the primary key.
• IGC_CCA_PK — The composite primary key (CC_HEADER_ID, CC_ACTION_NUM), the surrogate/identifying key for each action row.
• CC_ACTION_VERSION_NUM — Version stamp for the action, supporting multi-version tracking of contract changes.
• CC_ACTION_TYPE — The category of action performed (e.g., approval, amendment, cancellation).
• CC_ACTION_STATE — Current state of the action within its lifecycle.
• CC_ACTION_CTRL_STATUS — Control or processing status, indicating where the action sits in its operational flow.
• CC_ACTION_APPRVL_STATUS — Approval status of the action, indicating whether required approvals have been obtained.
• CC_ACTION_NOTES — Free-form descriptive notes recorded against the action.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — Standard Oracle EBS WHO columns providing audit lineage.

A unique index, IGC_CC_ACTIONS_U1, exists on (CC_HEADER_ID, CC_ACTION_NUM), confirming this composite as the business-key candidate and reinforcing the natural uniqueness of an action within a contract.

Common Use Cases and Queries

Typical reporting needs center on contract action history, approval tracking, and audit reconstruction. A common query retrieves all actions for a contract in sequence:

• SELECT CC_ACTION_NUM, CC_ACTION_TYPE, CC_ACTION_STATE, CC_ACTION_APPRVL_STATUS, CC_ACTION_NOTES FROM IGC.IGC_CC_ACTIONS WHERE CC_HEADER_ID = :header_id ORDER BY CC_ACTION_NUM;

Analysts also aggregate by action type or approval status to report on contract throughput, pending approvals, or action volumes by period, joining the WHO columns (CREATION_DATE, CREATED_BY) for audit trail reporting. Because the table is satellite-leaning and version-aware (CC_ACTION_VERSION_NUM), variance and change-history reporting across contract revisions is a natural fit.

Related Objects

The most significant relationship is with the parent contract entity. The documented foreign key shows IGC_CC_ACTIONS.CC_HEADER_ID referencing the contract header table, joined on CC_HEADER_ID. Related objects for reporting purposes include:

• IGC_CC_HEADERS (or the corresponding contract header table) — parent via CC_HEADER_ID.
• IGC_CC_ACTION_HISTORY / version tables — track prior action versions aligned to CC_ACTION_VERSION_NUM.
• IGC_CC_LINES and related commitment line tables — contract detail joined through the shared CC_HEADER_ID.
• Contract Commitment workflow/approval views — driven by CC_ACTION_APPRVL_STATUS and CC_ACTION_STATE.
• Contract Commitment public APIs — used to create and transition contract actions.

Together these objects support end-to-end contract action tracking within the IGC module.