Search Results igc_cc_approval_status




Overview

The view APPS.IGC_CC_ACTIONS_V is a denormalized reporting view within the Oracle E-Business Suite Grants (IGC) module, specifically serving the Contract Commitment (CC) action-tracking framework. It presents a flat, human-readable representation of commitment control actions recorded in the base table IGC_CC_ACTIONS, enriching each row with decoded meanings resolved from FND_LOOKUPS and with the creating user's name resolved from FND_USER. Because the underlying numeric or coded status values are translated into descriptive text through outer joins to the lookup table, the view is the preferred access point for ad-hoc queries, BI Publisher reports, OAF/Forms region data sources, and integration extracts that must expose approval and control status in a legible form. It is particularly relevant to searches for igc_cc_approval_status, since the view is the documented layer at which the approval status code CC_ACTION_APPRVL_STATUS is joined to lookup type IGC_CC_APPROVAL_STATUS and surfaced as CC_ACTION_APPRVL_STATUS_DESC.

Underlying Base Objects

The view is defined over one primary transactional table and three lookup/identity sources. Documented base objects are IGC_CC_ACTIONS (synonym), FND_LOOKUPS (view), FND_USER (synonym), and the FND_GLOBAL package. IGC_CC_ACTIONS CCA supplies the driving rows. Four aliased instances of FND_LOOKUPS — LKP1, LKP2, LKP3, and LKP4 — participate as outer-joined decode sources keyed on lookup types IGC_CC_ACTION_TYPE, IGC_CC_STATE, IGC_CC_CONTROL_STATUS, and IGC_CC_APPROVAL_STATUS. FND_USER FNDU is inner-joined on USER_ID = CCA.CREATED_BY to supply USER_NAME. All lookup joins use the Oracle outer-join operator (+), ensuring action rows survive even when a lookup code is unmapped.

Key Columns

Common Use Cases and Queries

Typical scenarios include reviewing pending or rejected commitments by approval status, auditing who created each action, and feeding commitment control state into downstream reporting extracts. A simple status inquiry:

  • SELECT CC_HEADER_ID, CC_ACTION_NUM, CC_ACTION_APPRVL_STATUS_DESC, CC_ACTION_CTRL_STATUS_DESC FROM APPS.IGC_CC_ACTIONS_V WHERE CC_ACTION_APPRVL_STATUS = 'PENDING';
  • SELECT CC_HEADER_ID, CC_ACTION_TYPE_DESC, CC_ACTION_APPRVL_STATUS_DESC, USER_NAME, CREATION_DATE FROM APPS.IGC_CC_ACTIONS_V WHERE CC_HEADER_ID = :header_id ORDER BY CC_ACTION_NUM, CC_ACTION_VERSION_NUM;
  • SELECT CC_ACTION_APPRVL_STATUS, CC_ACTION_APPRVL_STATUS_DESC, COUNT(*) FROM APPS.IGC_CC_ACTIONS_V GROUP BY CC_ACTION_APPRVL_STATUS, CC_ACTION_APPRVL_STATUS_DESC;

Because the view joins to FND_LOOKUPS with outer joins, the _DESC columns may be null where a code is not listed in the lookup, and queries should therefore key on the coded column when filtering. No WHERE predicate is embedded in the view beyond the join to FND_USER, so clients must supply their own header or date restrictions.