Search Results igc_cc_actions_u1




Overview

IGC.IGC_CC_ACTIONS is a transactional audit table within the Oracle E-Business Suite Contracts Commitment (IGC) module. It records the significant actions that have been performed against a contract commitment, capturing the lifecycle history of each commitment defined in IGC.IGC_CC_HEADERS. The relationship between the two tables is one-to-many: for each row in IGC_CC_HEADERS there may be one or more corresponding rows in IGC_CC_ACTIONS. Rows are inserted automatically by the system whenever discrete events occur, such as initiation, transition between states, or approval, so the table functions as a system-maintained action log rather than a user-maintained entity.

The object is owned by the IGC schema, carries FND Design Data reference IGC.IGC_CC_ACTIONS, holds a VALID status, and resides in the APPS_TS_TX_DATA tablespace with a PCT FREE of 10. Its uniqueness constraint, index IGC_CC_ACTIONS_U1, is defined on the combination of CC_HEADER_ID and CC_ACTION_NUM and is implemented as a NORMAL UNIQUE index in the APPS_TS_TX_IDX tablespace. From a Data Vault modeling perspective, the heuristic classification of this table is satellite-leaning, since it stores descriptive, versioned action context keyed to a parent commitment rather than serving as a standalone hub or a pure many-to-many link.

Key Information Stored

The 13 documented columns fall into three groups: identifying keys, action state descriptors, and standard WHO audit columns.

  • CC_HEADER_ID (NUMBER) — the contract commitment defining column, forming the leading portion of the composite key and joining back to the parent header record.
  • CC_ACTION_NUM (NUMBER) — the contract commitment action line number, which sequences the actions recorded against a given header.
  • CC_ACTION_VERSION_NUM (NUMBER) — the contract commitment version number associated with the action.
  • CC_ACTION_TYPE (VARCHAR2) — the category of action committed against the contract.
  • CC_ACTION_STATE (VARCHAR2) — the state of the contract at the time of the action.
  • CC_ACTION_CTRL_STATUS (VARCHAR2) — the control status of the contract commitment.
  • CC_ACTION_APPRVL_STATUS (VARCHAR2) — the approval status of the contract commitment.
  • CC_ACTION_NOTES (VARCHAR2, 240) — free-formatted text describing the nature of the action.

The primary key is documented as IGC_CCA_PK over (CC_HEADER_ID, CC_ACTION_NUM). The unique index IGC_CC_ACTIONS_U1 mirrors those same two columns, making them the business-key candidates in the physical model. The remaining five columns are the standard WHO audit set: LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, and CREATED_BY. LAST_UPDATED_BY and CREATED_BY reference FND_USER.USER_ID, and LAST_UPDATE_LOGIN references FND_LOGINS.LOGIN_ID.

Common Use Cases and Queries

The table is most often queried to reconstruct the action history of a commitment, to report on approval and control status transitions, and to audit who performed which action and when. A typical history query joins the child actions to the parent header and orders by the action sequence number:

  • SELECT a.cc_action_num, a.cc_action_type, a.cc_action_state, a.cc_action_apprvl_status, a.creation_date FROM igc.igc_cc_actions a WHERE a.cc_header_id = :header_id ORDER BY a.cc_action_num;
  • Joining IGC_CC_ACTIONS to IGC_CC_HEADERS on CC_HEADER_ID to display the current header attributes alongside the chronological action trail.
  • Filtering by CC_ACTION_TYPE or CC_ACTION_APPRVL_STATUS to report on how many commitments reached approval and how long each transition took, using CREATION_DATE as the event timestamp.
  • Auditing actions performed by a specific user by joining LAST_UPDATED_BY or CREATED_BY to FND_USER.USER_ID.

Related Objects

The most significant dependencies are centered on the parent commitment and the standard reference tables:

  • IGC.IGC_CC_HEADERS — the parent table, joined on CC_HEADER_ID, holding the commitment definition to which each action belongs.
  • IGC.IGC_CC_ACTIONS_U1 — the unique index enforcing uniqueness on (CC_HEADER_ID, CC_ACTION_NUM).
  • FND_USER — referenced by LAST_UPDATED_BY and CREATED_BY for user identification.
  • FND_LOGINS — referenced by LAST_UPDATE_LOGIN for operating-system login attribution.
  • IGC_CC_ACTIONS subordinate views and the IGC Contracts Commitment concurrent programs that insert rows automatically during initiation, transition, and approval processing.