Search Results oks_k_order_contacts_u2

Overview

The OKS.OKS_K_ORDER_CONTACTS table is an Oracle Service Contracts (OKS) child entity that records party contacts defined for an individual service order line. Service order lines are interfaced from Oracle Order Management into Oracle Service Contracts, and during that flow the Contract Details form is invoked for each line. Contacts entered at that point are persisted in this table. Multiple contacts can be defined for a single service order line, supporting scenarios where several parties — customer representatives, internal responders, or third-party agents — must be associated with the same contracted service.

In an ETRM-style modeling view, the documented foreign key structure suggests this object behaves as a link table: it resolves the many-to-many relationship between service order details and party contacts, carrying the contact role as descriptive context. This classification is a heuristic derived from the FK topology and should be treated as a modeling suggestion rather than a prescriptive definition.

Key Information Stored

The table holds twelve documented columns, of which the following are the most operationally significant:

• ID — the surrogate primary key and unique identifier for each contact record, enforced by unique index OKS_K_ORDER_CONTACTS_U1 and the primary key constraint OKS_K_ORDER_CONTACTS_PK.
• COD_ID — contract details unique identifier, referencing OKS_K_ORDER_DETAILS.ID; this is the association to the underlying service order line.
• CRO_CODE — the contact role, sourced from the FND_LOOKUP lookup type OKC_CONTACT_ROLE.
• OBJECT1_ID1 — the party contact identifier, referencing HZ_RELATIONSHIPS.PARTY_ID; this is the substantive contact reference.
• OBJECT1_ID2 — reserved and documented as not used.
• JTOT_OBJECT_CODE — foreign key to JTF_OBJECTS_B that identifies the view referenced by the OBJECT_ID columns; the documented value is OKX_PCONTACT, which is the source of the "okx_pcontact" search term.
• OBJECT_VERSION_NUMBER — optimistic locking sequence, set to 1 on insert and incremented on update.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard audit columns.
• SECURITY_GROUP_ID — legacy virtual private database column, now obsolete.

Two unique indexes exist. OKS_K_ORDER_CONTACTS_U1 covers ID alone. OKS_K_ORDER_CONTACTS_U2 covers the composite business key (COD_ID, CRO_CODE, OBJECT1_ID1, OBJECT1_ID2), which together guarantee that a contact participates once in a given role on a given order line. Data is stored in the APPS_TS_TX_DATA tablespace, with indexes in APPS_TS_TX_IDX and a PCT Free of 10.

Common Use Cases and Queries

Typical reporting scenarios include listing all contacts on a service order line, resolving a party ID to a customer name, or filtering orders by contact role. A representative join pattern follows:

• Join OKS_K_ORDER_CONTACTS to OKS_K_ORDER_DETAILS on COD_ID = OKS_K_ORDER_DETAILS.ID to obtain the service line context.
• Join OKS_K_ORDER_CONTACTS to HZ_RELATIONSHIPS on OBJECT1_ID1 = PARTY_ID to resolve the contact party.
• Join to FND_LOOKUP_VALUES on CRO_CODE = LOOKUP_CODE with LOOKUP_TYPE = 'OKC_CONTACT_ROLE' to render the role description.
• Filter on JTOT_OBJECT_CODE = 'OKX_PCONTACT' when isolating contacts whose object reference resolves through the OKX_PCONTACT view.
• Always exclude obsolete SECURITY_GROUP_ID logic in 12.1.1 and 12.2.2, where hosted VPD is no longer used.

Related Objects

• OKS_K_ORDER_DETAILS — parent of the COD_ID foreign key; holds the service order line detail.
• JTF_OBJECTS_B — referenced by JTOT_OBJECT_CODE; defines the view (OKX_PCONTACT) behind the OBJECT_ID columns.
• FND_SECURITY_GROUPS — referenced by the legacy SECURITY_GROUP_ID column.
• HZ_RELATIONSHIPS — referenced logically by OBJECT1_ID1 to resolve the party contact.
• FND_LOOKUP_VALUES — supplies the contact role description via OKC_CONTACT_ROLE.
• OKX_PCONTACT — the view identified by JTOT_OBJECT_CODE and the object named in the "okx_pcontact" search.