Search Results okc_article_trans_v




Overview
Explore in AI Chat

Overview

OKC_ARTICLE_TRANS_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the OKC – Contracts Core product family, the module responsible for the contract authoring, clause, and template functionality within Oracle Contracts. The view is documented with a status of VALID and is described in ETRM metadata as a view for the table OKC_ARTICLE_TRANSLATIONS.

Functionally, OKC_ARTICLE_TRANS_V exposes translation and versioning context for contract articles. Its name and column list indicate that it presents the article translation header data — the descriptive identity, category, clause, rule, and document reference attributes associated with a translated article row — together with the standard Oracle EBS audit columns. Because the view is a thin projection over the article translation entity rather than an aggregation or join-heavy reporting view, it is typically consumed by concurrent programs, Forms-based contract authoring screens, and custom integrations that must read or reconcile article translation records without touching the base table directly.

Underlying Base Objects

The view is defined over a single documented base object: the synonym OKC_ARTICLE_TRANS, which resolves to the underlying OKC_ARTICLE_TRANS table in the APPS schema. No additional joins, unions, or scalar subqueries appear in the documented view text; the SELECT list is a direct column projection from the base object, aliased as ATNB. The view therefore provides an indirection layer only — it does not denormalize or enrich the base data.

Two naming details warrant attention. First, the view name references OKC_ARTICLE_TRANS (the table used in the FROM clause), while the ETRM description names OKC_ARTICLE_TRANSLATIONS. Both refer to the same conceptual entity — the article translation records — and the discrepancy reflects the historic table naming convention rather than a distinct object. Second, the ROW_ID column is populated from ATNB.ROWID, exposing the physical row identifier of the base table row. This is significant: ROW_ID is a pseudo-column value and is not stable across table reorganization, export/import, or row migration, so it must not be persisted or used as a durable foreign key.

Key Columns

  • ROW_ID – the base table ROWID, useful for direct row access within a session but not portable.
  • ID – the primary identifier of the article translation record.
  • OBJECT_VERSION_NUMBER – the optimistic locking / versioning column used by the Oracle EBS framework to detect concurrent updates.
  • CAT_ID – the category identifier associated with the article translation.
  • CLE_ID – the clause identifier, linking the translation to its source clause definition.
  • RUL_ID – the rule identifier associated with the article.
  • DNZ_CHR_ID – the document or contract header identifier (donor/documents zone contracts header) to which the article translation belongs.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – the standard Oracle EBS who-columns recording creation and last modification audit information.

Common Use Cases and Queries

Typical uses include data extraction for contract migration, reconciliation of article translations against their source clauses, and debugging of contract authoring behavior. A basic query lists all translations for a given contract document:

  • SELECT id, cat_id, cle_id, rul_id, dnz_chr_id, object_version_number
    FROM okc_article_trans_v
    WHERE dnz_chr_id = :p_contract_id;

Audit-oriented queries filter on the audit columns to identify recently changed translation rows:

  • SELECT id, dnz_chr_id, last_updated_by, last_update_date
    FROM okc_article_trans_v
    WHERE last_update_date >= TRUNC(SYSDATE) - 7;

Because the view exposes no descriptive text columns beyond the identifiers, consumers requiring translated article text must join the result to the appropriate translation text or language tables using ID, CLE_ID, and CAT_ID. Queries should always project explicit columns rather than SELECT *, since ROW_ID is neither stable nor intended for persistent storage.