Search Results oks_k_lines_tlh_pk

Overview

OKS_K_LINES_TLH is a Service Contracts (OKS) module table that stores historical text attribute information for service contract lines. Within the Oracle E-Business Suite R12.1.1 and 12.2.2 data model, OKS_K_LINES_TLH functions as the history repository for structured textual content associated with contract line definitions, such as invoice text, transaction details, and status narration. The table preserves prior versions of these text attributes so that changes made to contract lines over time remain auditable and traceable.

The owner/schema is OKS, and the object holds VALID status in both release levels. The documented physical schema for 12.2.2 reports 15 columns.

The Data Vault classification mined from the foreign-key structure is standalone. Under Data Vault modeling conventions, a standalone table with no inbound dependent links is typically modeled as a hub or reference table rather than a link or satellite. This classification is a heuristic suggestion derived from relationship mining; teams building a Data Vault representation should validate it against actual query patterns before committing to a hub design.

Key Information Stored

The table is keyed by a composite primary key, OKS_K_LINES_TLH_PK, defined on (ID, MAJOR_VERSION, LANGUAGE). This three-part surrogate key identifies a specific historical version of a text attribute set for a given contract line and language, and it is the mechanism that preserves version history. A unique index, OKS_K_LINES_TLH_U1, covers (ID, LANGUAGE, MAJOR_VERSION) — the same three business-key columns in a different ordinal sequence, confirming that ID, MAJOR_VERSION, and LANGUAGE together constitute the business-key candidate for this object.

The most significant columns are:

• ID — Identifier linking the historical text record to its originating contract line context.
• MAJOR_VERSION — Version discriminator that distinguishes successive revisions of the same text attribute set.
• LANGUAGE — Language code supporting multilingual contract text.
• SOURCE_LANG — Source language of the text, used for translation tracking.
• SFWT_FLAG — Flag indicating whether the record is the "source" or current version for a given identifier/version combination.
• INVOICE_TEXT — Invoice-related narrative text for the contract line.
• IB_TRX_DETAILS — Installed Base transaction detail text associated with the line.
• STATUS_TEXT — Status narration describing the line's state at the time the version was captured.
• REACT_TIME_NAME — Name of the reaction time attribute referenced by the line.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS, providing multi-tenant data isolation.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS WHO columns recording audit and concurrent-program context.

Common Use Cases and Queries

Typical uses involve auditing contract line text changes, reporting on prior invoice or transaction wording, and reconstructing the state of a contract line at a point in time. Because the table is history-oriented, most queries filter on ID and then order by MAJOR_VERSION to retrieve the version chain.

A representative pattern retrieving the version history of text attributes for a given identifier:

• SELECT id, major_version, language, invoice_text, status_text, last_update_date FROM oks.oks_k_lines_tlh WHERE id = :line_id ORDER BY major_version, language;
• Security-aware reporting adds WHERE security_group_id = :sg_id to constrain results to the appropriate operating group.
• Change tracking joins the history rows to the current line table on ID and selects rows where MAJOR_VERSION exceeds the current version, isolating superseded text.
• Multilingual reporting filters on LANGUAGE and SOURCE_LANG to compare translated text against its source.

Related Objects

The documented foreign key references FND_SECURITY_GROUPS through SECURITY_GROUP_ID, which anchors the table to the EBS multi-org security framework. The table also participates in the broader OKS Service Contracts lineage through its ID column, which corresponds to the contract line identifier used by parent OKS line and header tables and by the historical text tables that parallel this object (for example, the header-level text history). Standard WHO audit columns link to FND_USER through CREATED_BY and LAST_UPDATED_BY.

Because the mined relationship data classifies OKS_K_LINES_TLH as standalone, direct programmatic dependencies are limited; consumers typically reach it through Service Contracts application logic and reporting views rather than through declared foreign keys to the OKS line tables.