Search Results igc_cc_mc_headers




Overview
Explore in AI Chat

Overview

IGC_CC_MC_HEADERS is a table in the IGC (Contract Commitment) product module of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. Per the ETRM documentation, its description is "Multiple reporting currency table for contracts." In practice, this table stores the currency conversion attributes associated with contract headers so that a single contract can be reported in multiple reporting currencies beyond its functional currency. Each row represents the conversion parameters — type, date, and rate — that apply to a specific contract header within a specific set of books.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. Under a Data Vault modeling suggestion, this implies the table behaves neither purely as a hub nor as a dependent satellite of another hub in the mined graph; it carries its own composite key and attributes. Modeling teams should treat it as a standalone entity keyed by the contract header and set of books combination.

The documented physical schema in ETRM 12.2.2 records the owner as IGC with five columns and one primary key, IGC_CC_MC_HEADERS_PK.

Key Information Stored

The table contains five documented columns. The most important are the key columns and the conversion attributes:

  • CC_HEADER_ID — Identifier of the parent contract header. Together with SET_OF_BOOKS_ID it forms the primary key.
  • SET_OF_BOOKS_ID — The set of books (reporting ledger) for which the multiple reporting currency conversion applies.
  • CONVERSION_TYPE — The Oracle General Ledger currency conversion type (for example, Spot or Corporate) used to translate the contract amounts into the reporting currency.
  • CONVERSION_DATE — The effective date on which the conversion rate is applied.
  • CONVERSION_RATE — The rate used to convert the contract's functional currency amount into the target reporting currency.

The surrogate primary key documented is IGC_CC_MC_HEADERS_PK, composed of (CC_HEADER_ID, SET_OF_BOOKS_ID). The unique index IGC_CC_MC_HEADERS_U1 covers the identical column pair (CC_HEADER_ID, SET_OF_BOOKS_ID), confirming it as the business-key candidate. No separate surrogate column exists; the natural business key and the primary key coincide.

Common Use Cases and Queries

Typical scenarios include reporting contract commitments in a reporting currency, reconciling translations at period close, and auditing which conversion rate was applied to a given contract. A common query retrieves the conversion attributes for a contract:

  • SELECT cc_header_id, set_of_books_id, conversion_type, conversion_date, conversion_rate FROM igc.igc_cc_mc_headers WHERE cc_header_id = :p_header_id;
  • Joining to the contract header table to obtain contract amounts in the reporting currency, filtering by a specific set of books.
  • Comparing conversion rates across sets of books for the same contract during reconciliation.
  • Listing all contracts having a conversion_date within a given accounting period to validate rate application.

Because the table is keyed by (CC_HEADER_ID, SET_OF_BOOKS_ID), queries filtering on both columns benefit from the unique index. Reports should restrict by set of books to avoid mixing functional and reporting currency figures.

Related Objects

The following objects are significant in relation to IGC_CC_MC_HEADERS, joined on the documented key columns:

  • IGC_CC_HEADERS — The parent contract header table; join on CC_HEADER_ID to retrieve contract attributes alongside conversion data.
  • IGC_CC_HEADERS_PK — The primary key definition of the parent contract header, referenced by CC_HEADER_ID.
  • GL_SETS_OF_BOOKS — The ledger definition; join on SET_OF_BOOKS_ID to resolve currency and ledger names.
  • GL_DAILY_CONVERSION_TYPES — Supplies valid values for CONVERSION_TYPE.
  • GL_DAILY_RATES — The rate table underlying CONVERSION_RATE and CONVERSION_DATE, used to validate the stored rate.
  • IGC_CC_MC_DETAILS (if present in the schema) — Line-level multiple reporting currency data dependent on the header.

Team members should confirm the presence of dependent detail tables in their specific 12.1.1 or 12.2.2 instance, as ETRM documents only the header object here.