Search Results trn_code




Overview
Explore in AI Chat

Overview

OKC_K_HISTORY_V is a PL/SQL-based view owned by the APPS schema in Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2. It belongs to the OKC — Contracts Core product family and exposes the contract lifecycle history for contract records managed by Oracle Contracts. The view consolidates the base transactional data from OKC_K_HISTORY_B with the translatable, language-dependent content from OKC_K_HISTORY_TL, presenting a single denormalized row per contract history entry for the currently active session language.

In Oracle EBS reporting and integration architecture, this view serves as the primary read-only interface for auditing and reporting on status transitions applied to a contract. Each row captures a discrete history event — for example, a status change, an approval action, or a manual update recorded against a contract header or contract line. Because it is a view over the underlying (_B and _TL) tables, it provides the benefits of simplified access without duplicating data, while remaining consistent with the DFF/translation model used throughout OKC.

Underlying Base Objects

The documented base objects referenced by OKC_K_HISTORY_V are two synonyms in the APPS schema:

  • OKC_K_HISTORY_B — the base transactional table holding non-translatable history attributes such as identifiers, status codes, the transaction code, and standard WHO/audit columns.
  • OKC_K_HISTORY_TL — the translatable table that stores language-specific descriptive content, principally the COMMENTS column, keyed by ID and LANGUAGE.

The view definition joins these two objects on the shared ID column and restricts the TL rows using HSTT.LANGUAGE = USERENV('LANG'). This ensures that a query returns only the history comments in the caller's session language, falling back to the base language behavior configured for the EBS environment. Both base objects are exposed to the APPS schema through synonyms, which is the standard pattern for OKC product tables.

Key Columns

  • ROW_ID — the ROWID of the underlying OKC_K_HISTORY_B row; useful in update-style processing that must target the physical base row.
  • ID — the primary history identifier shared between the _B and _TL tables.
  • CHR_ID — the contract header identifier to which the history entry belongs.
  • CLE_ID — the contract line identifier, where the history event applies at line level rather than header level.
  • CONTRACT_VERSION and OBJECT_VERSION_NUMBER — support versioning and optimistic concurrency control for the contract record at the time of the event.
  • OPN_CODE — operation code describing the action that generated the history record.
  • STS_CODE_FROM / STS_CODE_TO — the previous and resulting status codes, forming the core of the status transition audit trail.
  • REASON_CODE — the reason associated with the transition, where one was supplied.
  • TRN_CODE — the transaction code indicating how the history entry was generated (for example, by a specific UI action, workflow, or concurrent program). This is frequently used by users searching for "trn_code" to classify or filter history records by originating transaction.
  • MANUAL_YN — indicates whether the update was performed manually versus by an automated process.
  • COMMENTS — the translatable, language-dependent descriptive text from OKC_K_HISTORY_TL.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
  • PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, REQUEST_ID — concurrent program and request context that last touched the row.

Common Use Cases and Queries

Typical uses center on contract status auditing, approval tracking, and workflow diagnostics. The following query returns all history entries for a given contract header, showing the status transition and the transaction that drove it:

  • SELECT ID, CHR_ID, CLE_ID, STS_CODE_FROM, STS_CODE_TO, TRN_CODE, MANUAL_YN, COMMENTS, CREATION_DATE FROM OKC_K_HISTORY_V WHERE CHR_ID = :p_chr_id ORDER BY CREATION_DATE;

To isolate events generated by a particular transaction type for troubleshooting or reconciliation:

  • SELECT CHR_ID, STS_CODE_FROM, STS_CODE_TO, REASON_CODE, TRN_CODE, CREATION_DATE FROM OKC_K_HISTORY_V WHERE TRN_CODE = :p_trn_code AND CREATION_DATE >= :p_from_date;

For manual-versus-automatic analysis, a representative aggregation is:

  • SELECT MANUAL_YN, TRN_CODE, COUNT(*) FROM OKC_K_HISTORY_V GROUP BY MANUAL_YN, TRN_CODE;

Because OKC_K_HISTORY_V already enforces the session-language join, reporting queries do not need to join OKC_K_HISTORY_TL explicitly, reducing complexity while preserving multilingual correctness in EBS 12.1.1 and 12.2.2 environments.