Search Results cc_hdr_id

Overview

IGC_CC_HDRS_MAX_DATES_V is a reporting view owned by the APPS schema within the IGC - Contract Commitment product family of Oracle E-Business Suite. The view is registered as VALID in ETRM for both 12.1.1 and 12.2.2 and presents, for each contract commitment header, the single most recent activity timestamp recorded against that header and any of its dependent child records. The view resolves the analytical question "when was this contract commitment last touched?" by aggregating the LAST_UPDATE_DATE column across six transactional sources and returning the maximum value.

The view is a pure read-only aggregation object. It does not store data, participates in no concurrent program or workflow, and exposes no DML surface. Its practical role is to support reporting, integration extracts, and change-detection logic where the identity of the changed child record is irrelevant and only the effective last-touched date of the commitment matters. A user searching for "activity_date" will typically be attempting to reconcile the LAST_UPDATE_DATE column of an underlying table with the promoted column exposed here, which is aliased MAX_ACTIVITY_DATE.

Underlying Base Objects

The view is defined by a union of six grouped subqueries wrapped in an outer GROUP BY CC_HDR_ID. Each subquery returns a contract header identifier and a maximum LAST_UPDATE_DATE, and the outer query takes the maximum of those values.

• IGC_CC_HEADERS (ICH) — the primary header row; contributes ICH.LAST_UPDATE_DATE grouped by CC_HEADER_ID.
• IGC_CC_HEADER_HISTORY (ICHH) — audit history of header changes; contributes ICHH.LAST_UPDATE_DATE.
• IGC_CC_ACCT_LINES (ICAL) — account distribution lines belonging to the header; contributes ICAL.LAST_UPDATE_DATE.
• IGC_CC_ACCT_LINE_HISTORY (ICALH) — history of account line changes.
• IGC_CC_DET_PF (ICDP) — detail/performance obligation records joined to ICAL on CC_ACCT_LINE_ID.
• IGC_CC_DET_PF_HISTORY (ICDPH) — history of the detail records, joined to ICAL on CC_ACCT_LINE_ID.

All six objects are referenced as APPS synonyms, meaning the view resolves them through the standard synonym layer rather than through hard-coded schema prefixes. Any change to the LAST_UPDATE_DATE of a row in any of these six tables is therefore reflected in the view output.

Key Columns

• CC_HDR_ID — the contract commitment header identifier. This is the CC_HEADER_ID from IGC_CC_HEADERS and functions as the join key back to the header entity. It is the only grouping column in the view.
• MAX_ACTIVITY_DATE — the derived maximum LAST_UPDATE_DATE across all contributing rows for the given header. This is the column surfaced when a user searches for "activity_date." It represents the most recent point in time at which the commitment, its account lines, its detail/performance obligations, or any of their history rows were modified.

Because the column is an aggregate, it is never NULL for a header that exists in IGC_CC_HEADERS; at minimum the header row itself supplies a value.

Common Use Cases and Queries

The view is most often used for incremental extracts, change monitoring, and audit reporting. Typical patterns include selecting all headers modified since a given date, or joining the view to the header entity to display a last-activity column in a report.

• Identify commitments changed within a window: SELECT CC_HDR_ID, MAX_ACTIVITY_DATE FROM IGC_CC_HDRS_MAX_DATES_V WHERE MAX_ACTIVITY_DATE >= :p_from_date ORDER BY MAX_ACTIVITY_DATE DESC;
• Return the activity date for a single header: SELECT MAX_ACTIVITY_DATE FROM IGC_CC_HDRS_MAX_DATES_V WHERE CC_HDR_ID = :p_cc_hdr_id;
• Join to the header for descriptive reporting: SELECT h.CC_HEADER_ID, h.CONTRACT_NUMBER, v.MAX_ACTIVITY_DATE FROM IGC_CC_HEADERS h, IGC_CC_HDRS_MAX_DATES_V v WHERE h.CC_HEADER_ID = v.CC_HDR_ID;
• Feed a delta-load routine by comparing MAX_ACTIVITY_DATE against a stored watermark to determine which commitments require re-extraction.

Because the view aggregates history tables as well as current tables, it detects changes that would be invisible if only IGC_CC_HEADERS were queried. This makes it the appropriate source for watermark-based synchronization and for confirming that no dependent line or detail modification has occurred since a prior extract.