Search Results okc_k_rel_objs_v




Overview
Explore in AI Chat

Overview

OKC_K_REL_OBJS_V is a documented view in the Oracle E-Business Suite Contracts Core (OKC) module, owned by the APPS schema and marked VALID. Its stated purpose in the ETRM metadata is straightforward: it is a view for the table OKC_K_REL_OBJS. In practice, the view presents a read-only, fully column-mapped projection of the contract related-objects entity, exposing every persisted attribute of the underlying table without joins, filters, or derived logic. This design makes the view a stable, DBA-sanctioned access point for reporting and integration consumers who should not query the base table directly.

Because the view is a one-to-one passthrough, its role in Oracle EBS 12.1.1 and 12.2.2 is predominantly as a reporting and integration surface. Oracle's ETRM documentation follows a long-standing convention in which "_V" views (and their "_UV" counterparts) are published as the supported interface for external reads, allowing Oracle to alter physical storage or internal structure in the base table while preserving the view's contract. Any concurrent program, BI Publisher data template, or outbound interface that needs contract related-object data can be built against this view with a reasonable expectation of stability across 12.1.1 and 12.2.2.

Underlying Base Objects

The ETRM metadata documents exactly one referenced base object: the synonym OKC_K_REL_OBJS, which resolves to the base table of the same name in the OKC schema. The deployment is minimal — no additional tables, lookup views, or outer joins are referenced. The view text is a single SELECT of aliased columns (CRJB being the alias for OKC_K_REL_OBJS) from that table, with ROWID exposed as ROW_ID.

The first column in the projection is CRJB.ROWID ROW_ID, a conventional EBS pattern that gives consumers a stable row identifier independent of the primary key. The remaining columns map name-for-name to base table attributes, including the object version number, the related-object identifiers, the WHO columns, and the fifteen descriptive flexfield attribute columns. Because of this strict one-to-one mapping, the view is not a denormalized reporting convenience view in the traditional sense; it is a structural abstraction layer. Any predicate, sort, or aggregation applied against the view is pushed directly to the base table, so performance characteristics match querying OKC_K_REL_OBJS itself.

Key Columns

The view exposes thirty columns. The most operationally significant include:

  • ROW_ID — the base table ROWID, providing a unique physical row locator for the related-objects record.
  • ID — the primary key of the related-object row, and OBJECT_VERSION_NUMBER, used for optimistic locking and concurrent-update detection.
  • CLE_ID — the contract line or contract-header entity identifier that the related object is associated with; this is typically the driving foreign key in reporting queries.
  • CHR_ID — the contract relationship identifier linking the related object to its parent relationship record.
  • RTY_CODE — the relationship type code that classifies the nature of the association.
  • OBJECT1_ID1 and OBJECT1_ID2 — the composite identifier of the related object (for example, a party, item, or document reference), interpreted together with JTOT_OBJECT1_CODE.
  • JTOT_OBJECT1_CODE — the object type code that determines how OBJECT1_ID1 and OBJECT1_ID2 should be resolved (for instance, against a party or inventory entity).
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the descriptive flexfield columns, carrying client-specific context and segment values.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns, useful for incremental extraction and audit reporting.

Common Use Cases and Queries

The primary use cases are contract reporting, interface extraction, and reconciliation. A typical query retrieves all related objects for a given contract line:

  • SELECT id, cle_id, chr_id, rty_code, object1_id1, object1_id2, jtot_object1_code FROM okc_k_rel_objs_v WHERE cle_id = :p_cle_id;
  • SELECT object1_id1, object1_id2, jtot_object1_code FROM okc_k_rel_objs_v WHERE rty_code = :p_rty_code AND attribute_category = :p_category;
  • SELECT id, object_version_number FROM okc_k_rel_objs_v WHERE last_update_date >= :p_since; for incremental change extraction based on the WHO columns.

Because the view is a passthrough, consumers should apply selective predicates on CLE_ID, CHR_ID, or the object identifier columns and rely on the base table's indexed access paths; unfiltered scans of this view will read every row in OKC_K_REL_OBJS. Joining the view to contract header and line tables on CLE_ID is the standard pattern for producing contract-detail reports that include their associated objects, and joining on JTOT_OBJECT1_CODE allows resolution of the related object to its source entity. All access should remain read-only, with DML performed through the supported OKC APIs, since the view is provided for retrieval rather than maintenance.