Search Results partner_org




Overview

OKC.OKC_REP_PARTY_CONTACTS is a transactional table in the Oracle E-Business Suite Contracts (OKC) schema that stores the contacts associated with a party participating in a contract. It functions as the bridge between a contract party role and the specific contact person or contact organization maintained for that party. The table is central to contract authoring, approval routing, and notification logic, where the correct contact for a supplier, customer, partner, or internal organization must be resolved at runtime.

The party's role determines the source of truth for the contact. A contact whose party carries the role SUPPLIER_ORG is drawn from PO_VENDOR_CONTACTS; a contact whose party carries the role CUSTOMER_ORG or PARTNER_ORG is drawn from HZ_PARTIES; and a contact whose party carries the role INTERNAL_ORG is drawn from PER_PEOPLE_F. This design allows a single contract repository to unify supplier, customer, partner, and internal contacts without duplicating the underlying party model.

From a heuristic Data Vault modeling perspective, this object is best classified as a link: it resolves a many-to-many relationship between a contract party, the underlying party/organization, and the contact record, while also carrying descriptive attributes such as OBJECT_VERSION_NUMBER and ESIGNATURE_TYPE that lean satellite-like. The classification is a suggestion; the authoritative structure is the relational and foreign-key design documented below.

Key Information Stored

The table contains 17 documented columns. The most operationally significant are:

The unique business-key index OKC_REP_PARTY_CONTACTS_U1 spans CONTRACT_ID, PARTY_ID, PARTY_ROLE_CODE, CONTACT_ID, and CONTACT_ROLE_ID, ensuring a contact role is recorded only once per party per contract. The non-unique index OKC_REP_PARTY_CONTACTS_N1 on CONTACT_ID supports reverse lookups from a contact to its contracts.

Common Use Cases and Queries

Typical reporting and integration scenarios include contract contact rosters, notification routing, and e-signature sequencing. A common query joins the table to contract and party metadata:

SELECT rpc.contract_id,
       rpc.party_id,
       rpc.party_role_code,
       rpc.contact_id,
       rcr.contact_role_code
FROM   okc.okc_rep_party_contacts rpc,
       okc.okc_rep_contact_roles_b rcr
WHERE  rpc.contact_role_id = rcr.contact_role_id
AND    rpc.contract_id = :p_contract_id;

For partner scenarios, filtering by PARTY_ROLE_CODE = 'PARTNER_ORG' isolates partner contacts sourced from HZ_PARTIES, which is the pattern most relevant to the "partner_org" search. Reverse lookups use the N1 index to find all contracts for a given contact:

SELECT contract_id, party_id, party_role_code
FROM   okc.okc_rep_party_contacts
WHERE  contact_id = :p_contact_id;

Integration routines should respect OBJECT_VERSION_NUMBER to prevent lost updates when contact assignments change concurrently.

Related Objects

  • OKC.OKC_REP_CONTRACTS_ALL — parent contract; joined via CONTRACT_ID.
  • OKC.OKC_REP_CONTRACT_PARTIES — contract-party association; referenced via CONTRACT_PARTY_ID.
  • OKC.OKC_REP_CONTACT_ROLES_B — contact role definitions; referenced via CONTACT_ROLE_ID.
  • PO.PO_VENDOR_CONTACTS — source of contacts for SUPPLIER_ORG parties.
  • HZ.HZ_PARTIES — source of contacts for CUSTOMER_ORG and PARTNER_ORG parties.
  • PER.PER_PEOPLE_F — source of contacts for INTERNAL_ORG parties.
  • OKC public contract APIs that create and maintain contract party contacts, which must supply the current OBJECT_VERSION_NUMBER.