Search Results okc_condition_headers_tl_pk

Overview

The OKC_CONDITION_HEADERS_TL table resides in the OKC schema (Contracts Core module) and stores the translatable, language-dependent descriptive columns for contract condition headers. It is the Multi-Lingual Support (MLS) companion table to OKC_CONDITION_HEADERS_B, which holds the language-independent base attributes. In Oracle EBS 12.1.1 and 12.2.2, this MLS architecture allows the same condition header to be presented in multiple installed languages, with each row representing one translation of a single condition header in a specific LANGUAGE.

Condition headers define reusable terms, clauses, and contract conditions that drive pricing, entitlement, and obligation logic across Oracle Contracts and related modules. Because users must read and author these conditions in their own language, the translation table plays a central role in the usability of the Contracts Core data model. Based on the heuristic Data Vault classification mined from the documented foreign key structure — which is essentially a standalone relationship with only a security group reference — this object is best modeled as a satellite, attached to the language-independent hub represented by OKC_CONDITION_HEADERS_B. This is a modeling suggestion rather than a physical constraint enforced by Oracle.

Key Information Stored

The table contains fifteen documented columns, and the most significant are described below. The primary key OKC_CONDITION_HEADERS_TL_PK is composed of ID and LANGUAGE, where ID is the surrogate key that links back to the base table OKC_CONDITION_HEADERS_B, and LANGUAGE is the NLS language code of the translation. A unique index, OKC_CONDITION_HEADERS_TL_U1 (ID, LANGUAGE, ZD_EDITION_NAME), acts as a business-key candidate and supports edition-based data management via the ZD_EDITION_NAME column.

• ID — Surrogate key inherited from and shared with the base table; identifies the condition header being translated.
• LANGUAGE — The NLS language code for the row; together with ID forms the primary key.
• SOURCE_LANG — Language of the source record from which the translation was derived, per MLS convention.
• SFWT_FLAG — Standard "Seed/Firm/Working/Translated" abbreviation used in MLS to track translation status.
• NAME — The translated name of the condition header, the primary user-facing identifier.
• DESCRIPTION — The full translated description of the condition.
• SHORT_DESCRIPTION — A concise translated form used in list-of-values and summary displays.
• COMMENTS — Free-form translated remarks supplied by the author.
• ZD_EDITION_NAME — Editioning column supporting Oracle Edition-Based Redefinition, part of the unique business-key index.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, enforcing Multi-Org security on the record.

The audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN follow standard Oracle Applications WHO-column conventions and are populated automatically by the application tier.

Common Use Cases and Queries

Because the TL table is the presentation layer for condition text, virtually all user-facing queries against conditions join it to the base table filtered by the session language. A typical query to retrieve the English name and description of all condition headers is:

• SELECT b.id, t.name, t.description FROM okc_condition_headers_b b, okc_condition_headers_tl t WHERE b.id = t.id AND t.language = USERENV('LANG') AND t.source_lang = USERENV('LANG');
• Reporting on untranslated conditions by comparing SOURCE_LANG to LANGUAGE and inspecting SFWT_FLAG to identify rows still in working/seed status.
• Building language-specific list-of-values for contract authoring forms, returning NAME and SHORT_DESCRIPTION for the desired LANGUAGE.
• Auditing translation completeness across a multi-language implementation by grouping counts by LANGUAGE.
• Data extraction for downstream BI or data-warehouse feeds where each condition header is flattened with its localized text.

Related Objects

The following objects are most significant when working with OKC_CONDITION_HEADERS_TL:

• OKC_CONDITION_HEADERS_B — The base table; joined on ID, holding language-independent attributes.
• OKC_CONDITION_HEADERS_VL — The MLS view that automatically joins the _B and _TL tables by the current language, and is the recommended access point for application logic.
• OKC_CONDITION_HEADERS_TL_PK — The primary key constraint on (ID, LANGUAGE).
• OKC_CONDITION_HEADERS_TL_U1 — Unique business-key index on (ID, LANGUAGE, ZD_EDITION_NAME).
• FND_SECURITY_GROUPS — Referenced via SECURITY_GROUP_ID for Multi-Org security enforcement.
• OKC_CONDITIONS_B / OKC_CONDITIONS_TL — Child condition tables that reference condition headers and inherit their translation pattern.
• FND_LANGUAGES — Supplies valid values for LANGUAGE and SOURCE_LANG and drives the NLS environment.