Results for “okc_k_lines_tlh_u1”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

OKC.OKC_K_LINES_TLH is a translation history table in the Oracle E-Business Suite Contracts (OKC) schema. It serves as the historical, versioned counterpart to the base translation table OKC_K_LINES_TL, which stores language-dependent descriptive attributes for contract lines across the multiple languages installed in an EBS instance. The "TLH" suffix denotes the historical accumulation of prior translation row versions, keyed by a major version number so that each change to a translated line attribute is preserved as a discrete record. In EBS 12.1.1 and 12.2.2 the table resides in the APPS_TS_TX_DATA tablespace, is owned by OKC, and carries the FND design data designation OKC.OKC_K_LINES_TLH.

The ETRM metadata classifies this object heuristically as standalone under a Data Vault lens, meaning it exhibits no outbound foreign keys to other business entities apart from a reference to FND_SECURITY_GROUPS. In Data Vault modeling terms this suggests a satellite-style structure attached to a contract line hub via the ID column, rather than a hub or link in its own right. The history-preserving MAJOR_VERSION column acts as the effectivity/version discriminator typical of satellite tables.

Key Information Stored

The primary key is documented as OKC_K_LINES_TLH_PK, spanning ID, LANGUAGE, and MAJOR_VERSION. The user's search term, OKC_K_LINES_TLH_U1, corresponds to the unique index of the same three columns, which is therefore both the business-key candidate and, together with the primary key constraint, the access path used to resolve a specific translated version.

The most significant columns are:

• ID — surrogate identifier tying the translated row to its parent contract line in the base structure.
• LANGUAGE — the installed language code (for example US, DE, FR) identifying which translation is stored.
• MAJOR_VERSION — the version number that distinguishes historical snapshots of the same line/language combination.
• SOURCE_LANG — the language from which the translation was derived.
• SFWT_FLAG — flag indicating whether the row has been processed by the translation "seed/fallback" workflow.
• NAME — the translated short name of the contract line.
• COMMENTS and ITEM_DESCRIPTION — translated long-text attributes describing the line.
• BLOCK23TEXT — an additional translated descriptive block.
• OKE_BOE_DESCRIPTION — description text shared with the Oracle Knowledge/OKE ordering context.
• COGNOMEN — an alternate identifying name for the line.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit trail.
• SECURITY_GROUP_ID — the only documented foreign key, referencing FND_SECURITY_GROUPS for row-level security partitioning.

Common Use Cases and Queries

The table is queried for two primary purposes: auditing translation changes over time, and reconstructing the translated text that was in force at a prior point. A typical audit query selects all versions for one line across languages:

SELECT id, language, major_version, source_lang, name
FROM   okc.okc_k_lines_tlh
WHERE  id = :p_line_id
ORDER  BY language, major_version;

To retrieve only the latest translated name per language, reporting logic typically filters on a correlated maximum of MAJOR_VERSION, since the table holds the full history rather than only current values. Comparing SFWT_FLAG values across versions also supports reconciliation of translation workflow runs.

Related Objects

• OKC_K_LINES_TL — the base translation table the history mirrors; join on ID and LANGUAGE for current values.
• OKC_K_LINES_B — the base contract line table supplying ID.
• OKC_K_LINES_TL_H variants and other OKC translation history tables follow the same pattern.
• FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID.
• FND_LANGUAGES — supplies valid LANGUAGE and SOURCE_LANG codes.
• OKC_K_LINES_V — the standard view layer used by contract forms and APIs.
• OKC contract APIs (for example OKC_CONTRACT_PUB) read and write the corresponding TL rows, whose changes propagate into this history.