Search Results contact_role_code




Overview
Explore in AI Chat

Overview

OKI_K_CONTACTS_V is an APPS-owned, VALID database view belonging to the OKI (Contracts Intelligence) product family within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to expose information about contract contacts — the parties, resources, and roles associated with a contract — in a denormalized, reporting-friendly shape. The view combines the transactional contact assignments stored in OKC_CONTACTS with the contract header attributes held in the Contracts Intelligence sales header table OKI_SALES_K_HDRS, and resolves both the contact name and the contact role meaning through reference lookups and resource views.

Because Contracts Intelligence is fundamentally an analytical and reporting layer, OKI_K_CONTACTS_V is intended primarily for queries, extracts, and downstream integrations that need a stable, human-readable rendition of who is associated with a given contract and in what capacity. It is not a base table and should not be written to; it is a read-only projection over the OLTP contact model.

Underlying Base Objects

The ETRM metadata documents no explicit base objects for this view, but the view definition itself references four sources:

  • OKC_CONTACTS — the core contact assignment table, aliased as CTT. Supplies the surrogate identifier, the contract foreign key, the contact role code, the party-role identifier, the resource identifier, and the descriptive flexfield attribute columns (ATTRIBUTE_CATEGORY through ATTRIBUTE15).
  • OKI_SALES_K_HDRS — the Contracts Intelligence sales header, aliased as SHD. Supplies CONTRACT_NUMBER, CONTRACT_NUMBER_MODIFIER, and the concatenated COMPLETE_CONTRACT_NUMBER, and is also used to drive the access-level check.
  • FND_LOOKUPS — the standard Oracle lookup table, aliased as CRO, filtered on LOOKUP_TYPE = 'OKC_CONTACT_ROLE', providing the translated meaning for the contact role code.
  • OKX_RESOURCES_V and OKX_PARTY_CONTACTS_V — resource/party views (aliased OKX) used to resolve the contact name, joined on ID1 = CTT.OBJECT1_ID1.

The view is defined as a UNION of two branches. Both branches filter on JTOT_OBJECT1_CODE to distinguish the underlying object type (for example OKX_RESOURCE versus a party-contact object), which is why two different OKX views are required. Both branches additionally apply OKC_UTIL.GET_K_ACCESS_LEVEL(SHD.CHR_ID, SHD.SCS_CODE) IN ('R','U'), restricting the result set to contracts the current user can Read or Update. This access-level predicate is a critical behavioral characteristic: query results are session- and responsibility-dependent, not a complete unfiltered list.

Key Columns

  • PARTY_CONTACT_ID — surrogate identifier of the contact record (OKC_CONTACTS.ID).
  • CONTRACT_ID — the Contracts Intelligence contract identifier (DNZ_CHR_ID), the join key to the contract header.
  • CONTRACT_NUMBER, CONTRACT_NUMBER_MODIFIER, COMPLETE_CONTRACT_NUMBER — the contract number and its modifier, plus the fully formatted number used in user-facing displays.
  • PARTY_ROLE_ID — the party role identifier (CPL_ID) on the contact.
  • CONTACT_ROLE_CODE, CONTACT_ROLE_MEANING — the lookup code drawn from the OKC_CONTACT_ROLE lookup type and its translated meaning. This is the column directly relevant to searches for okc_contact_role; the role vocabulary is derived from that lookup type.
  • CONTACT_ID, CONTACT_NAME — the resource/party identifier and resolved display name of the contact.
  • CREATION_DATE, LAST_UPDATE_DATE — standard audit columns.
  • ATTRIBUTE_CATEGORY, ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield context and segment values carried through from the contact record.

Common Use Cases and Queries

Typical uses include contact rosters per contract, role-based distribution lists, and reconciliation between the customer-facing contract number and the internal contact assignments. A representative query lists all contacts for contracts of interest with their role:

  • Filtering by CONTACT_ROLE_CODE or CONTACT_ROLE_MEANING to build role-specific extracts (for example, all "Buyer" or "Contract Administrator" contacts).
  • Joining CONTRACT_ID back to contract header views to combine contact data with financial or status attributes.
  • Selecting the descriptive flexfield attributes for downstream integration payloads that require contract-specific contact metadata.

Because the view enforces GET_K_ACCESS_LEVEL, results differ by user session; any integration or report that expects a complete contact population must account for this restriction. Also note the TO_NUMBER(CTT.OBJECT1_ID1) conversion on the contact identifier — malformed values in that column can raise conversion errors, so defensive filtering is advisable when querying directly.