Search Results okc_condition_headers

Overview

OKC_CONDITION_HEADERS_HV is an APPS-owned, VALID database view within the OKC – Contracts Core product module of Oracle E-Business Suite (documented for 12.1.1 and 12.2.2). It functions as the history view for the OKC_CONDITION_HEADERS entity, exposing the complete version history of contract condition header records rather than only the currently active row. The "_HV" suffix denotes the history view convention used throughout Contracts Core, meaning that every major version of a condition header is preserved and made queryable. This distinguishes it from the operational (non-history) base view that surfaces only the current definition.

For reporting and integration purposes, the view is significant because contract conditions are version-controlled business objects. Analysts, extensions, and downstream interfaces frequently require visibility into how a condition was defined at a point in time — for example, when its DATE_ACTIVE or DATE_INACTIVE values were set. Because OKC_CONDITION_HEADERS_HV retains all major versions, it supports audit, trend analysis, and effective-dated reporting.

Underlying Base Objects

The view is defined over two synonyms in the APPS schema:

• OKC_CONDITION_HEADERS_BH — the "_BH" (base history) table holding the versioned, language-independent attributes of each condition header, including its major version.
• OKC_CONDITION_HEADERS_TLH — the "_TLH" (translation, language, history) table holding the language-dependent descriptive text for each version.

The join is performed on ID and MAJOR_VERSION, with an additional filter on LANGUAGE = USERENV('LANG') so that translated columns (NAME, DESCRIPTION, SHORT_DESCRIPTION, COMMENTS, SFWT_FLAG) are returned in the session's language. The ROW_ID column is derived from the BH table's ROWID. This structure mirrors the standard Oracle version-controlled entity pattern of a base-history table joined to a translation-history table.

Key Columns

Given the user's interest in "date_active," the DATE_ACTIVE column is central. It records the date from which the condition version becomes effective, and it is paired with DATE_INACTIVE, which marks the date the condition ceases to be effective. Together they support effective-dated queries and identify whether a condition was active on a given date.

Other notable columns include:

• ID and MAJOR_VERSION — uniquely identify a condition header and its specific version.
• CONDITION_VALID_YN — indicates whether the condition version is valid.
• ONE_TIME_YN, TEMPLATE_YN, TRACKED_YN, SEEDED_FLAG — behavioral and origin flags.
• BEFORE_AFTER, CNH_TYPE, CNH_VARIANCE — classification and sequencing attributes.
• DNZ_CHR_ID, ACN_ID, COUNTER_GROUP_ID, OBJECT_ID, JTOT_OBJECT_CODE — foreign-key linkages to related contract objects.
• SFWT_FLAG, NAME, DESCRIPTION, SHORT_DESCRIPTION, COMMENTS — language-dependent text.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, LAST_RUNDATE, APPLICATION_ID — audit and concurrency columns.
• ATTRIBUTE1 through ATTRIBUTE15 — the standard DFF/descriptive flexfield columns.

Common Use Cases and Queries

Typical scenarios include auditing condition validity windows, reconciling active conditions across versions, and exporting historical condition data for integration. A common query retrieves all versions of a condition with their effective dates:

SELECT id, major_version, name, date_active, date_inactive, condition_valid_yn
FROM   apps.okc_condition_headers_hv
WHERE  id = :p_condition_id
ORDER  BY major_version;

To find conditions active on a specific date:

SELECT id, major_version, name, date_active, date_inactive
FROM   apps.okc_condition_headers_hv
WHERE  :p_as_of_date BETWEEN date_active AND NVL(date_inactive, :p_as_of_date);

Because the view is read-only, all access is via SELECT statements. Queries should filter by ID or date ranges where possible, since the history tables grow with every version created.