Search Results contact_role_code

Overview

OKS_ENT_PARTY_CONT_V is a reporting view owned by the APPS schema within the Oracle Service Contracts (OKS) module. It exposes a consolidated list of party contacts associated with service contract headers, resolving contact role codes into their descriptive meanings. The view is defined over contract header, party role, and contact base objects, joined to the FND_LOOKUPS view to translate the OKC_CONTACT_ROLE lookup into a human-readable role name.

In Oracle EBS 12.1.1 and 12.2.2, this view supports reporting, integration, and diagnostic activity where a flat, denormalized picture of contract-to-contact relationships is required. It removes the need for consumers to reconstruct the multi-table join between contract headers, party roles, and contacts, and to decode contact role lookups independently. Its status is VALID and it is documented in the ETRM repository, confirming that it is a supported reporting object rather than an internal helper.

Underlying Base Objects

The view text joins four principal sources. OKC_K_HEADERS_B supplies the contract header, exposed as CONTRACT_ID. OKC_K_PARTY_ROLES_B provides the party role row that links a contract to a contact through the DNZ_CHR_ID column, and its ID becomes CONTACT_ROLE_ID. OKC_CONTACTS supplies the contact record itself, exposed as CONTACT_ID, and carries the CRO_CODE column that identifies the contact role. FND_LOOKUPS is joined on LOOKUP_CODE equal to CON.CRO_CODE, with LOOKUP_TYPE restricted to 'OKC_CONTACT_ROLE', to return the role meaning.

The documented 12.2.2 metadata lists the referenced base objects as FND_GLOBAL (package), FND_LOOKUPS (view), OKC_CONTACTS (synonym), OKC_K_HEADERS_ALL_B (synonym), and OKC_K_PARTY_ROLES_B (synonym). The presence of FND_GLOBAL reflects the standard Oracle EBS multi-org/flexfield pattern common to contract views; the _ALL_B and _B synonyms map to the underlying header and party role tables. Note that the party contact identifier is derived by converting PRL.OBJECT1_ID1 to a number, so the view assumes that attribute is populated for the rows returned.

Key Columns

• CONTRACT_ID — Identifier of the service contract header (HDR.ID).
• CONTACT_ID — Identifier of the contact record from OKC_CONTACTS (CON.ID).
• CONTACT_ROLE_ID — Identifier of the party role row (PRL.ID) linking contract to contact.
• PARTY_CONTACT_ID — Numeric form of PRL.OBJECT1_ID1, identifying the underlying party contact.
• CONTACT_ROLE_CODE — The CRO_CODE from the contact, matching lookup code in OKC_CONTACT_ROLE.
• CONTACT_ROLE_NAME — The FND_LOOKUPS meaning, giving the descriptive role name for reporting.

Common Use Cases and Queries

Typical uses include contract contact listings, role-based contact reporting, and integration extracts that need contact identities per contract. The following query returns all contacts for a specific contract:

• SELECT contact_id, party_contact_id, contact_role_code, contact_role_name FROM apps.oks_ent_party_cont_v WHERE contract_id = :p_contract_id;

Reporting by role across contracts is equally common, for example listing all contacts holding a given role:

• SELECT contract_id, contact_id, contact_role_name FROM apps.oks_ent_party_cont_v WHERE contact_role_code = :p_role_code ORDER BY contract_id;

Because the view resolves both identifiers and lookup meanings, it is well suited to downstream extracts and to validating that required contract roles (such as primary or billing contacts) exist before integration processing.