Results for “okc_k_items”

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

Overview

OKC.K_ITEMS is a Contracts Core (OKC) transactional table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores item-level attributes for contract lines. Where OKC_K_LINES_B captures the commercial line itself (pricing, quantities, and header associations), OKC_K_ITEMS persists the item detail attached to those lines — the inventory item references, unit of measure, quantity, and pricing flags that determine how a contract line behaves during fulfillment, billing, and entitlement processing. The object is owned by the OKC schema and is classified as VALID in the ETRM repository, with 25 documented columns in the 12.2.2 physical schema.

From a Data Vault modeling perspective, the heuristic classification mined from the foreign key structure is satellite-leaning: the table is anchored to parent contract headers and lines rather than acting as an independent hub or a pure many-to-many link. It should therefore be modeled as a descriptive satellite attached to the contract-line hub, with its own change history driven by OBJECT_VERSION_NUMBER and the standard WHO audit columns.

Key Information Stored

• ID — the surrogate primary key (OKC_K_ITEMS_PK), also exposed through the unique index OKC_K_ITEMS_U1. This is the single documented business-key candidate; no composite natural key is defined in the metadata.
• CLE_ID — foreign key to OKC_K_LINES_B; identifies the contract line to which the item belongs.
• CHR_ID — foreign key to OKC_K_HEADERS_B; the owning contract header. Together with CLE_ID this denormalizes the header context onto each item row for efficient querying.
• CLE_ID_FOR — a second reference to OKC_K_LINES_B, typically used to record a related or "for" line (for example, a covering or entitlement line) distinct from the primary line.
• JTOT_OBJECT1_CODE — foreign key to JTF_OBJECTS_B; identifies the object type of the referenced item, allowing OKC to attach heterogeneous item entities (inventory items, service items, and so on).
• OBJECT1_ID1 / OBJECT1_ID2 — the composite object identifier (for example, inventory item ID and organization) resolved against JTOT_OBJECT1_CODE.
• UOM_CODE — unit of measure for the item quantity.
• NUMBER_OF_ITEMS — the quantity of the item on the contract line.
• PRICED_ITEM_YN and EXCEPTION_YN — flags indicating whether the item is priced and whether it is flagged as an exception during contract processing.
• DNZ_CHR_ID — the denormalized contract header identifier retained for performance-oriented joins.
• OBJECT_VERSION_NUMBER, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard concurrency and WHO audit set used by the Contracts UI and by interfaces loading item data.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enforcing multi-org/security-group data isolation in a shared schema.
• PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE, REQUEST_ID — concurrent program and request context, valuable for tracing which batch process inserted or updated a row.

Common Use Cases and Queries

The most frequent requirement is reconstructing the full contract hierarchy — header, line, and item — for a given contract. A standard join pattern is:

SELECT h.contract_number, l.line_number, i.object1_id1, i.uom_code,
       i.number_of_items, i.priced_item_yn
FROM   okc_k_headers_b h,
       okc_k_lines_b   l,
       okc_k_items     i
WHERE  h.id = l.chr_id
AND    l.id = i.cle_id
AND    h.id = :contract_header_id;

Reporting teams use OKC_K_ITEMS to produce item-level contract entitlement reports, priced versus unpriced item exception listings (filtering on EXCEPTION_YN = 'Y'), and quantity roll-ups by UOM. Interface and reconciliation queries filter on REQUEST_ID or the PROGRAM_* columns to audit which concurrent request populated or modified rows, while change-tracking queries use LAST_UPDATE_DATE against OBJECT_VERSION_NUMBER to detect concurrent updates. Because the table carries SECURITY_GROUP_ID, any custom SQL must respect the caller's security group, or it should be executed through the OKC security views rather than directly against the base table.

Related Objects

• OKC_K_HEADERS_B — joined on OKC_K_ITEMS.CHR_ID = OKC_K_HEADERS_B.ID; the contract header parent.
• OKC_K_LINES_B — joined on OKC_K_ITEMS.CLE_ID = OKC_K_LINES_B.ID and, for the secondary reference, OKC_K_ITEMS.CLE_ID_FOR = OKC_K_LINES_B.ID.
• JTF_OBJECTS_B — joined on OKC_K_ITEMS.JTOT_OBJECT1_CODE = JTF_OBJECTS_B.OBJECT_CODE to resolve the item object type.
• OKC_ITEM_PARTYS_B — references this table through OKC_ITEM_PARTYS_B.CIM_ID = OKC_K_ITEMS.ID; stores party role assignments for each contract item.
• FND_SECURITY_GROUPS — joined on OKC_K_ITEMS.SECURITY_GROUP_ID to enforce data security.
• OKC_K_ITEMS_PK / OKC_K_ITEMS_U1 — the primary key constraint and supporting unique index on ID, used by all referential lookups into this table.