Results for “contact_sequence”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

OKC_CONTACTS is a core table in the Oracle Contracts (OKC) module, which forms part of the Oracle E-Business Suite Contract Lifecycle Management (CLM) and Order Capture foundation. The table stores the individuals who act as contact points or are otherwise named on a contract, such as internal sales representatives, external customer contacts, legal signatories, and administrative points of contact. Each row associates a specific contact person, represented through a party role, with the contract object on which that person appears.

The table is owned by the OKC schema and, in Oracle EBS 12.1.1 and 12.2.2, is documented as VALID with 37 physical columns. Its primary key is OKC_CONTACTS_PK, defined on the ID column, and it carries two unique business-key candidates: OKC_CONTACTS_U1 (ID) and OKC_CONTACTS_U2, the latter spanning CPL_ID, CRO_CODE, JTOT_OBJECT1_CODE, OBJECT1_ID1, OBJECT1_ID2, and START_DATE.

From a data modeling perspective, the documented foreign key structure suggests a satellite-leaning classification. OKC_CONTACTS references OKC_K_PARTY_ROLES_B, JTF_OBJECTS_B, and FND_SECURITY_GROUPS, meaning it extends party-role hubs and multi-purpose object definitions with descriptive contact attributes rather than acting as an independent hub of its own.

Key Information Stored

The most significant columns capture the identity of the contact, the contract context, and the effective dates of the association.

• ID — The surrogate primary key (OKC_CONTACTS_PK) uniquely identifying each contact record.
• CPL_ID — Foreign key to OKC_K_PARTY_ROLES_B, linking the contact to a specific party role on the contract. Combined with CRO_CODE, it forms part of unique index OKC_CONTACTS_U2.
• CRO_CODE — The contact role code, indicating the function the contact performs (for example, signatory or sales contact) within unique index OKC_CONTACTS_U2.
• JTOT_OBJECT1_CODE — A JTF multi-purpose object code referencing JTF_OBJECTS_B, identifying the type of object the contact belongs to; also part of OKC_CONTACTS_U2.
• OBJECT1_ID1, OBJECT1_ID2 — Object identifier components used with JTOT_OBJECT1_CODE to resolve the specific parent object; both appear in OKC_CONTACTS_U2.
• DNZ_CHR_ID, DNZ_STE_CODE — Denormalized contract and statement identifiers retained for query performance.
• START_DATE, END_DATE — Effective dating for the contact assignment; START_DATE participates in the OKC_CONTACTS_U2 business key.
• PRIMARY_YN — Flag indicating whether the row represents the primary contact for the associated object.
• CONTACT_SEQUENCE — Ordering value for displaying multiple contacts.
• RESOURCE_CLASS, SALES_GROUP_ID — Classification and sales group context, the latter used by OKS_K_SALES_CREDITS for sales credit assignment.
• OBJECT_VERSION_NUMBER — Optimistic locking counter for concurrent updates.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard EBS audit columns.
• SECURITY_GROUP_ID — Foreign key to FND_SECURITY_GROUPS supporting multi-org and data security access.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — The standard DFF (descriptive flexfield) columns for customer-defined extensions.

Common Use Cases and Queries

Report writers and integrations query OKC_CONTACTS to enumerate the named parties on a contract for legal documents, sales credit validation, and contact directories. A typical pattern joins the table back to OKC_K_PARTY_ROLES_B through CPL_ID to resolve party and role descriptions:

SELECT c.ID, c.CONTACT_SEQUENCE, c.CRO_CODE, c.PRIMARY_YN,
       c.START_DATE, c.END_DATE
FROM   OKC.OKC_CONTACTS c
WHERE  c.DNZ_CHR_ID = :contract_id
AND    NVL(c.END_DATE, SYSDATE) >= SYSDATE
ORDER BY c.CONTACT_SEQUENCE;

Effective-dating filters (START_DATE/END_DATE) allow reports to isolate currently active contacts. Joining to OKS_K_SALES_CREDITS through CTC_ID supports sales credit reporting, while the SECURITY_GROUP_ID column is applied implicitly in multi-org secured queries. Integrations that populate or synchronize contact data should respect the U2 uniqueness constraint to avoid duplicating a contact for the same object, role, and start date.

Related Objects

• OKC_K_PARTY_ROLES_B — Referenced through OKC_CONTACTS.CPL_ID; supplies the party and role definition for each contact.
• JTF_OBJECTS_B — Referenced through OKC_CONTACTS.JTOT_OBJECT1_CODE; defines the multi-purpose object type the contact attaches to.
• FND_SECURITY_GROUPS — Referenced through OKC_CONTACTS.SECURITY_GROUP_ID; drives data security filtering.
• OKS_K_SALES_CREDITS — Depends on OKC_CONTACTS via OKS_K_SALES_CREDITS.CTC_ID; stores sales credit allocations tied to each contact.
• OKC_K_HEADERS_B / OKC_K_LINES_B — The contract header and line entities whose identifiers resolve through the denormalized DNZ_CHR_ID and object ID columns for contract-level contact listings.