Results for “okc_bus_doc_events_tl”

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

Overview

OKC_BUS_DOC_EVENTS_TL is a translation table in the OKC (Contracts Core) schema of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2. It stores the language-specific, translatable descriptive information associated with a Business Document Event. Business Document Events in OKC represent discrete lifecycle occurrences tied to a business document — for example, a contract approval, signature, submission, or expiry — and this table holds the human-readable meaning of each event in every installed language rather than the operational attributes of the event itself.

The object is documented as VALID and contains 10 columns in the 12.2.2 physical schema. Its ETRM data-vault classification is heuristic and mined from foreign-key structure: standalone. As a modeling suggestion, this reflects that the table carries no outbound foreign keys to other entities within the mined relationship graph; it functions as a dependent descriptive store keyed by its parent event identifier rather than as a hub or linking table. In practice it behaves as an internationalization (MLS) satellite of the base event entity.

Key Information Stored

The primary key, OKC_BUS_DOC_EVENTS_TL_PK, is the composite of BUS_DOC_EVENT_ID and LANGUAGE. BUS_DOC_EVENT_ID is the surrogate identifier of the parent Business Document Event; combined with LANGUAGE, it uniquely identifies one translated row. A second unique index, OKC_BUS_DOC_EVENTS_TL_U1, extends the key to include ZD_EDITION_NAME, confirming that edition tracking (as used by Oracle's adoption of edition-based redefinition in 12.2) participates in business-key uniqueness.

The principal descriptive payload is MEANING, which holds the translated text for the event. SOURCE_LANG records the language from which the translation was derived, supporting Oracle's standard MLS semantics. ZD_EDITION_NAME identifies the edition of the row. The remaining documented columns are standard audit attributes — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — which record insert/modify accountability and are consistent with the WHO columns found across EBS tables.

Common Use Cases and Queries

The most common requirement is resolving an event identifier to its display text in a session's language, typically by joining to the base event table. A representative pattern:

• Resolving meaning for a specific language: SELECT BUS_DOC_EVENT_ID, MEANING FROM OKC_BUS_DOC_EVENTS_TL WHERE LANGUAGE = USERENV('LANG') AND BUS_DOC_EVENT_ID = :id;
• Detecting missing translations: compare the count of rows in the base OKC_BUS_DOC_EVENTS-type table against counts in the TL table grouped by LANGUAGE, to find events lacking a localized meaning.
• Reporting event labels across languages: pivot MEANING by LANGUAGE with BUS_DOC_EVENT_ID as the grouping key, useful for translation audits and for building bilingual contract event logs.
• Edition-aware access: when running under EBR in 12.2, filter or join on ZD_EDITION_NAME to restrict results to the active edition.
• Audit extraction: query LAST_UPDATED_BY and LAST_UPDATE_DATE to trace when a translation was last changed.

Related Objects

The following objects are most significant in relation to this table:

• OKC_BUS_DOC_EVENTS (base entity) — joined on BUS_DOC_EVENT_ID; the parent event row that this translation table describes. This is the primary dependent relationship.
• OKC_BUS_DOC_EVENTS_TL_PK — the composite primary key constraint enforcing uniqueness of (BUS_DOC_EVENT_ID, LANGUAGE).
• OKC_BUS_DOC_EVENTS_TL_U1 — the unique index including ZD_EDITION_NAME, relevant for edition-aware lookups.
• FND_LANGUAGES — supplies the valid LANGUAGE codes and their installed/translatable status.
• OKC_BUS_DOC_EVENT_ATTRS and related OKC business document event attribute objects — supplementary metadata often queried alongside event meanings for complete reporting.
• OKC Contracts Core APIs that return event meanings for display in contract UI pages and concurrent reports, which implicitly read this TL table.

Because the table is classified as standalone with no mined outbound foreign keys, integrity is maintained through the application layer and the composite primary key rather than through declared referential constraints to other OKC entities.