Search Results okc_k_rel_objs




Overview
Explore in AI Chat

Overview

OKC_K_REL_OBJS is a Contracts Core (OKC) intersection table that links a contract header or contract line to other objects elsewhere in the E-Business Suite schema in a predefined manner. It is the physical realization of the contracts "related objects" model, allowing a single contract to be associated with external entities such as orders, projects, customers, or other contracts, and allowing those associations to be typed by a relationship code so that the semantics of each link are explicit rather than inferred.

Because each row carries both an owning contract reference (through CHR_ID or CLE_ID) and a pointer to an external object (through OBJECT1_ID1, OBJECT1_ID2, and JTOT_OBJECT1_CODE), the table functions as a junction between the contracts domain and the rest of the application schema. The documented primary key, OKC_K_REL_OBJS_PK, is defined on the ID column, and an additional unique index, OKC_CONTRACT_REL_OBJS_U1, is also defined on ID. Under the heuristic Data Vault classification mined from the foreign-key structure, this object is best modeled as a link: it records relationships between hubs (contracts and their related objects) rather than descriptive attributes of a single business entity.

Key Information Stored

The table is documented with 30 columns. The most significant are:

  • ID — surrogate primary key, enforced by OKC_K_REL_OBJS_PK and by the unique index OKC_CONTRACT_REL_OBJS_U1. This is the technical identifier of the relationship row itself.
  • CHR_ID — foreign key to OKC_K_HEADERS_B, identifying the contract header that owns the relationship.
  • CLE_ID — foreign key to OKC_K_LINES_B, identifying the contract line that owns the relationship.
  • RTY_CODE — the relationship type code, which defines the predefined manner in which the linked object is associated with the contract.
  • JTOT_OBJECT1_CODE — the object type code describing the class of the referenced external object.
  • OBJECT1_ID1 and OBJECT1_ID2 — the composite identifier values that locate the referenced object within its own domain.
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the Oracle Applications framework during concurrent updates.
  • SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, supporting multi-organization and security-group access control.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO columns tracking row creation and change auditing.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the DFF (descriptive flexfield) columns reserved for customer-specific extension of relationship data.

Note that neither CHR_ID, CLE_ID, nor SECURITY_GROUP_ID is documented as a uniqueness constraint; the only business-key candidate listed is the ID column itself. Therefore the business uniqueness of a contract-to-object association is governed by the relationship type (RTY_CODE) and the object reference columns, not by a single database constraint.

Common Use Cases and Queries

Typical reporting needs centre on enumerating everything related to a given contract, or conversely finding all contracts tied to a specific external object. A header-level query joins OKC_K_HEADERS_B to this table on CHR_ID; a line-level variant joins OKC_K_LINES_B on CLE_ID. Because both keys are nullable by usage pattern, most queries filter explicitly on the level required.

SELECT r.ID, r.RTY_CODE, r.JTOT_OBJECT1_CODE,
       r.OBJECT1_ID1, r.OBJECT1_ID2
FROM   OKC.OKC_K_REL_OBJS r
WHERE  r.CHR_ID = :contract_header_id;

A second pattern locates the owning contracts for a known external object, driving from JTOT_OBJECT1_CODE plus OBJECT1_ID1/ID2 and joining back to the header or line. A third pattern lists all relationships of a single type for a contract portfolio, using RTY_CODE as the discriminator. Security-conscious queries should also restrict on SECURITY_GROUP_ID, and DFF reporting can pivot on ATTRIBUTE_CATEGORY with the ATTRIBUTE1–15 columns.

Related Objects

The documented foreign keys and ownership relationships identify the following significant objects:

  • OKC_K_HEADERS_B — the contract header table; joined via OKC_K_REL_OBJS.CHR_ID.
  • OKC_K_LINES_B — the contract line table; joined via OKC_K_REL_OBJS.CLE_ID.
  • FND_SECURITY_GROUPS — the security group table; joined via OKC_K_REL_OBJS.SECURITY_GROUP_ID.
  • OKC_K_HEADERS_B / OKC_K_LINES_B via the OKC Contracts APIs (OKC_CONTRACT_PUB and related PL/SQL packages) — the supported programmatic path for creating and maintaining relationship rows rather than direct DML.

Because OBJECT1_ID1 and OBJECT1_ID2 are generic reference columns rather than enforced foreign keys, the set of downstream objects varies by RTY_CODE and JTOT_OBJECT1_CODE and must be resolved against the object type definition rather than assumed from the schema.