Search Results oks_k_order_contacts_v




Overview
Explore in AI Chat

Overview

OKS_K_ORDER_CONTACTS_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKS – Service Contracts product family. Its documented description is simply "view for Order contacts." The view exposes contact-role assignment records associated with service contract orders, presenting them through a stable, denormalized interface that shields consumers from the physical layout of the underlying table.

In EBS 12.1.1 and 12.2.2, the OKS schema stores a variety of service contract entities such as contracts, coverages, and party associations, most of which are keyed through the Oracle JTT (Journal/Transaction Table) framework. That framework uses generic column names like OBJECT1_ID1, OBJECT1_ID2, and JTOT_OBJECT_CODE to represent entity identifiers polymorphically. The _V naming convention signals that this is the supported API/reporting view for the entity, rather than the base table itself. It is the object that Forms, concurrent programs, and external integrations should query when reading order-contact data, and reports or interfaces built against it remain compatible across the 12.1.1 to 12.2.2 upgrade path.

Underlying Base Objects

According to the documented ETRM 12.2.2 metadata, OKS_K_ORDER_CONTACTS_V is defined over exactly one base object: OKS_K_ORDER_CONTACTS, accessed through its APPS synonym. The view definition is a straightforward, non-transforming projection of that table:

  • It selects each column from OKS_K_ORDER_CONTACTS COC with no joins, unions, or filters.
  • It derives a surrogate ROW_ID from COC.ROWID, giving consumers a unique physical row locator.
  • All remaining columns, including the JTT generic identifier columns and the standard who-columns, pass through unchanged.
  • Because the view is a simple one-to-one projection, inserts, updates, and deletes are not intended to be performed against it; DML belongs on the base table or the supported OKS APIs.

The status of the view is documented as VALID, confirming that the underlying table and synonym are present and correctly compiled in a standard installation.

Key Columns

The view exposes twelve columns, inherited directly from OKS_K_ORDER_CONTACTS:

  • ROW_ID — the ROWID of the underlying base-table row; useful for deduplication and high-water-mark processing.
  • ID — primary identifier for the order-contact record itself.
  • COD_ID — identifier linking the contact assignment to its parent contract/order document.
  • CRO_CODE — the contact-role code, e.g., the role a party plays on the order.
  • JTOT_OBJECT_CODE — the JTT object code that classifies the entity type being referenced.
  • OBJECT1_ID1 — the first generic identifier segment within the JTT model; for party-based contacts this typically holds the party identifier.
  • OBJECT1_ID2 — the second, qualifying identifier segment, which refines or disambiguates the value in OBJECT1_ID1 (for example, a party site or location).
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the OKS APIs to detect concurrent updates.
  • CREATED_BY / CREATION_DATE / LAST_UPDATED_BY / LAST_UPDATE_DATE — standard EBS audit (who) columns tracking record creation and last modification.

Because the JTT identifier columns carry no intrinsic foreign key, consumers must interpret OBJECT1_ID1/OBJECT1_ID2 in the context of JTOT_OBJECT_CODE and CRO_CODE to resolve the referenced party or contact.

Common Use Cases and Queries

Typical scenarios include reporting the parties associated with a service contract order, feeding order-contact data into integrations or OBIEE extracts, and validating contact-role assignments during order processing. A minimal query follows:

  • SELECT id, cod_id, cro_code, object1_id1, object1_id2 FROM apps.oks_k_order_contacts_v WHERE cod_id = :p_order_id; — lists contacts for a given order.
  • SELECT id, object1_id1, object1_id2 FROM apps.oks_k_order_contacts_v WHERE cro_code = :p_role AND object1_id1 = :p_party_id; — locates contacts playing a specific role for a party.
  • SELECT MAX(last_update_date) FROM apps.oks_k_order_contacts_v; — supports incremental extraction logic for ETL.

All queries should be qualified with APPS. and executed in a reporting context, since the view is a read interface and its underlying table is maintained solely through supported OKS code paths.