Search Results okc_governances_v




Overview
Explore in AI Chat

Overview

OKC_GOVERNANCES_V is a reporting and integration view owned by the APPS schema within the Oracle E-Business Suite Contracts Core (OKC) module. It is documented as valid in both EBS 12.1.1 and 12.2.2 and is defined as a wrapper over the OKC_GOVERNANCES base table. The view exposes governance relationships that associate a contract or contract line with the governing document, agreement, or standard that constrains it. In the Contracts Core data model, governance records express the hierarchical link between a governing instrument and the instrument it governs, such as an enterprise agreement that governs a subordinate contract, or a standard clause set that governs a line.

Because the view mirrors the base table columns one-to-one without filters or joins, its primary role is to provide a stable, documented read interface for SQL*Plus reports, BI Publisher data templates, Oracle Discoverer workbooks, and custom concurrent programs. Developers and integrators should treat OKC_GOVERNANCES_V as an approved access path rather than querying the base table directly, since the base table is subject to change while the view contract is maintained by Oracle.

Underlying Base Objects

The view is defined over a single object, OKC_GOVERNANCES, which is referenced in the view text through the alias GVEB. In the APPS schema this base object is exposed as a synonym pointing to the OKC schema table. The view text performs a plain projection of every column from the base table, adding only the ROWID pseudo-column aliased as ROW_ID. There are no WHERE clauses, no DISTINCT, no analytic functions, and no joins to other contract tables. Consequently, the view inherits the row population, indexing, and security characteristics of OKC_GOVERNANCES unchanged. Referential integrity with OKC_K_HEADERS, OKC_K_LINES, and related contract entities is enforced at the base table level through the CHR_ID and CLE_ID foreign key columns rather than through the view definition.

Key Columns

  • ROW_ID — the physical ROWID of the underlying OKC_GOVERNANCES row, useful for direct row addressing in update or diagnostic scripts.
  • ID — the primary key of the governance record, unique within OKC_GOVERNANCES.
  • DNZ_CHR_ID — the contract header identifier that owns the governance entry, typically the governing contract or the top-level contract in the governance hierarchy.
  • ISA_AGREEMENT_ID — identifier of the associated agreement where the governance relationship participates in an ISA (Integrated Service Agreement) style structure.
  • OBJECT_VERSION_NUMBER — optimistic locking column incremented on each update; critical for any programmatic DML against the base table.
  • CHR_ID and CLE_ID — the contract header and contract line identifiers of the governed entity.
  • CHR_ID_REFERRED and CLE_ID_REFERRED — the header and line identifiers of the referring or governing entity, establishing the direction of the governance link.
  • COPIED_ONLY_YN — flag indicating the governance row exists solely as a result of a copy operation rather than through deliberate user entry.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS who-columns used for audit reporting and change tracking.

Common Use Cases and Queries

Typical use cases include listing all governance links for a contract, identifying subordinate contracts governed by a master agreement, and auditing governance records copied during contract duplication. A representative query joining the view to the contract header is:

SELECT g.ID, g.CHR_ID, g.CHR_ID_REFERRED, g.CLE_ID_REFERRED, g.COPIED_ONLY_YN FROM OKC_GOVERNANCES_V g WHERE g.CHR_ID = :p_chr_id;

A governance tree report can be constructed by self-joining the view on CHR_ID_REFERRED to CHR_ID to reconstruct the governing hierarchy. Audit queries filtering on CREATION_DATE or LAST_UPDATE_DATE support change-inventory reporting, while filters on COPIED_ONLY_YN = 'Y' isolate governance rows generated by contract copy actions. Because the view is unfiltered, reports should always constrain by contract identifiers or date ranges to avoid full-table scans against large OKC installations.