Search Results igc_cc_access_u1

Overview

IGC.IGC_CC_ACCESS is a transaction-data table in the Oracle E-Business Suite IGC (Contract Commitment) schema that stores the access-control mapping between user access groups and individual contract commitments. Its stated purpose in the ETRM repository is to hold the information required to assign update privileges on individual contracts to groups of users. Functionally it is an intersection (association) entity: it resolves the many-to-many relationship between IGC_CC_GROUP_USERS and IGC_CC_HEADERS, so that for each contract more than one group user may hold access, and each group user may hold access to more than one contract. The table resides in the APPS_TS_TX_DATA tablespace with PCTFREE 10, consistent with other high-volume transactional IGC objects.

From a Data Vault modeling perspective, the mined metadata suggests a link classification: the table has no descriptive narrative of its own beyond the access level and access type attributes, and its dominant content is the association of surrogate keys (contract header, group, user) brought together with an access-defining key. Rows carry the standard WHO audit columns (LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY), which support change tracking regardless of the chosen model.

Key Information Stored

The table has 11 documented columns. The most significant for functional and join purposes are:

• CC_ACCESS_ID (NUMBER) — the access-defining column and the surrogate primary key. It is the single column of the unique index IGC_CC_ACCESS_U1 in tablespace APPS_TS_TX_IDX, and it is the business-key candidate documented for this object. This is also the column referenced in the search term "igc_cc_access_u1".
• CC_HEADER_ID (NUMBER) — the contract commitment defining column; identifies the IGC_CC_HEADERS row to which the access grant applies. It is indexed non-uniquely by IGC_CC_ACCESS_N1.
• CC_GROUP_ID (NUMBER) — the access group defining column; identifies the group granted privileges.
• USER_ID (NUMBER, length 15) — the user defining column; carries a documented foreign key to FND_USER.USER_ID.
• CC_ACCESS_LEVEL (VARCHAR2) — the contract access level granted to the group/user combination.
• CC_ACCESS_TYPE (VARCHAR2, length 10) — the contract access type, distinguishing the nature of the granted access.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — standard WHO audit columns; LAST_UPDATED_BY and CREATED_BY reference FND_USER.USER_ID and LAST_UPDATE_LOGIN references FND_LOGINS.LOGIN_ID.

The primary key IGC_CC_ACCESS_PK is defined on CC_ACCESS_ID, and the unique index IGC_CC_ACCESS_U1 enforces the same column as the business-key candidate.

Common Use Cases and Queries

Typical uses center on security reporting for contract commitments: identifying who can update a given contract, which contracts a given user or group can reach, and where access levels deviate from policy. Because the table is an access-governance link, reporting usually joins outward to the contract header, to the group definition, and to FND_USER.

• Access-by-contract: SELECT CC_HEADER_ID, CC_GROUP_ID, USER_ID, CC_ACCESS_LEVEL, CC_ACCESS_TYPE FROM IGC.IGC_CC_ACCESS WHERE CC_HEADER_ID = :p_header_id;
• Contracts reachable by a user: query on USER_ID filtered by CC_ACCESS_LEVEL and CC_ACCESS_TYPE to enumerate granted privileges.
• Group membership audit: join CC_GROUP_ID to the group/group-user objects to confirm each user's effective access.
• Data-fix and reconciliation: use CC_ACCESS_ID (the unique key) to target a single grant, or CC_HEADER_ID (via IGC_CC_ACCESS_N1) for bulk operations against all grants on one contract.
• The documented query text provides the canonical projection across all 11 columns from IGC.IGC_CC_ACCESS, suitable as a base for custom reports and extracts.

Related Objects

• FND_USER — referenced by USER_ID (and by the WHO columns LAST_UPDATED_BY / CREATED_BY). Primary join for resolving user identities.
• IGC_CC_HEADERS — the contract commitment parent; joined on CC_HEADER_ID. The table is documented as the association between group users and contract headers.
• IGC_CC_GROUP_USERS — the group-user side of the association; joined on CC_GROUP_ID.
• FND_LOGINS — referenced by LAST_UPDATE_LOGIN for operating-system login traceability.
• The documented dependencies state that IGC_CC_ACCESS does not reference any database object and is referenced by IGC objects; the FK metadata above supplies the operative join columns (USER_ID, CC_GROUP_ID, CC_HEADER_ID).

Because the metadata lists no dependent view or API names, the objects above are the significant documented join partners; any additional referencing packages or views in the IGC schema should be verified against the live 12.1.1 or 12.2.2 data dictionary before being relied upon.