Search Results okc_contacts_v




Overview
Explore in AI Chat

Overview

OKC_CONTACTS_V is a concurrent-safe, dictionary-managed view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the OKC (Contracts Core) product family and exists to present the rows of the base table OKC_CONTACTS with one important enrichment: the coded contact role is translated into a user-facing meaning through a lookup join. The view is documented in ETRM with a status of VALID, which indicates the definition is parsed and usable by the database. Reporting layers, contract authoring pages, and integration interfaces that need to render or extract contract contact data without carrying the raw lookup code typically query this view instead of the underlying table.

The view's defining query joins OKC_CONTACTS to FND_LOOKUPS on the condition that the lookup type equals 'OKC_CONTACT_ROLE' and the stored CRO_CODE equals the lookup code. As a result, each returned row contains all contact attributes plus a derived ROLE column holding the lookup MEANING rather than the internal code. This pattern is standard throughout EBS: coded values are exposed alongside their descriptions for display and reporting convenience.

Underlying Base Objects

The documented referenced objects for OKC_CONTACTS_V are OKC_CONTACTS (accessed through a synonym), FND_LOOKUPS (a view over the application lookup tables), and the FND_GLOBAL package. OKC_CONTACTS stores the contract contact assignment records, including the role code, the owning contract identifier, ordering sequence, effective dates, primary indicator, resource classification, and the standard EBS who-columns plus fifteen descriptive attributes.

The relationship to FND_LOOKUPS is expressed as an inner join in the view text, which means a contact row is only returned when a matching OKC_CONTACT_ROLE lookup code exists. FND_GLOBAL is referenced by EBS views of this generation to resolve session context, such as the current user and responsibility, in support of multi-org and auditing behavior. The view does not contain a WHERE clause restricting by DNZ_CHR_ID or date range, so filtering remains the responsibility of the calling query.

Key Columns

  • ROW_ID — the base table ROWID, used for direct row addressing in DML-through-view scenarios.
  • ID — primary identifier of the contact record within OKC_CONTACTS.
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the OA Framework to detect concurrent updates.
  • CPL_ID — the party or contact point identifier linking to the contact directory entry.
  • CRO_CODE — the raw contract role code stored in the base table.
  • ROLE — the lookup MEANING resolved from FND_LOOKUPS for lookup type OKC_CONTACT_ROLE.
  • DNZ_CHR_ID — the contract header identifier to which the contact is attached.
  • CONTACT_SEQUENCE — the display or processing order of the contact within the contract.
  • OBJECT1_ID1, OBJECT1_ID2, JTOT_OBJECT1_CODE — the generic party relationship and object-type reference used by the JTOT party model.
  • START_DATE, END_DATE — the effective dating window for the assignment.
  • PRIMARY_YN — flag identifying the primary contact for the contract.
  • RESOURCE_CLASS, SALES_GROUP_ID — resource and sales group classification attributes.
  • ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE15 — the standard DFF (descriptive flexfield) columns.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit who-columns.

Common Use Cases and Queries

Typical usage includes contract contact listings for a given contract, extraction of primary contact details for notifications, and integration feeds that require the human-readable role description. The following query returns all contacts for a contract along with the resolved role:

  • SELECT c.id, c.dnz_chr_id, c.cpl_id, c.role, c.primary_yn, c.start_date, c.end_date FROM apps.okc_contacts_v c WHERE c.dnz_chr_id = :p_contract_id ORDER BY c.primary_yn DESC, c.contact_sequence;
  • SELECT c.role, COUNT(*) FROM apps.okc_contacts_v c WHERE c.dnz_chr_id = :p_contract_id GROUP BY c.role;
  • SELECT c.id, c.cpl_id, c.role FROM apps.okc_contacts_v c WHERE c.primary_yn = 'Y' AND TRUNC(SYSDATE) BETWEEN c.start_date AND NVL(c.end_date, SYSDATE);

Because the role join is an inner join against FND_LOOKUPS, contacts whose CRO_CODE has no active OKC_CONTACT_ROLE lookup entry are excluded from the view; queries requiring every base-table row should select from OKC_CONTACTS directly. The view is read-oriented in practice, and applications perform contact maintenance against the base table.