Search Results oks_item_split

Overview

The OKS_ITEM_SPLIT table is a Service Contracts (OKS) module object in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to store the details of a contract line item both before and after a split operation. When a service contract line — or a covered item within a contract — is partially terminated, merged, reorganized, or otherwise divided into multiple parts, the system records the resulting transformation here. The table therefore preserves the audit and lineage trail of the split: the source item state and the target item state resulting from that division.

The ETRM metadata classifies this object heuristically as satellite-leaning within a Data Vault modeling approach. In practice this means OKS_ITEM_SPLIT is best treated as a descriptive/audit table that hangs off a parent business entity (the split event or the item), rather than as a standalone hub of business keys or a pure associative link. The classification derives from the self-referencing foreign key structure noted in the metadata, where OKS_ITEM_SPLIT.SPLIT_ID points back to OKS_ITEM_SPLIT itself.

Key Information Stored

The documented structure is intentionally compact. The most significant attributes are:

• ID — The surrogate primary key of the table, enforced by the constraint OKS_ITEM_SPLIT_PK. It uniquely identifies each split record row.
• SPLIT_ID — A documented foreign-key column and the principal business-relevant reference. Because the metadata shows SPLIT_ID referencing OKS_ITEM_SPLIT itself, this column links the record to the split event it describes. Depending on the row's role, it can identify the parent split or associate sibling rows generated by the same splitting action.

The separation of the surrogate key (ID) from the business-reference column (SPLIT_ID) is significant: ID provides row-level uniqueness, while SPLIT_ID carries the semantic grouping that ties "before" and "after" item states together. The metadata does not document additional descriptive columns such as item identifiers, quantities, dates, or status codes, so their presence should be confirmed against the live 12.1.1/12.2.2 dictionary before relying on them. The ETRM record notes the table is "Not implemented in this database," indicating it is not populated in the reference environment even though the definition exists.

Common Use Cases and Queries

Teams typically query OKS_ITEM_SPLIT to reconstruct how a service contract item was divided, to reconcile quantities or coverage across the resulting lines, and to support audit or data-migration validation. A basic retrieval of split records is:

• SELECT id, split_id FROM oks_item_split WHERE split_id = :p_split_id; — returns all rows belonging to one split event.
• SELECT id, split_id FROM oks_item_split ORDER BY split_id, id; — a listing pattern for reporting or extract.

Because the table is self-referencing, joining OKS_ITEM_SPLIT to itself on SPLIT_ID (aliasing parent and child) reconstructs the before/after relationship for a given split. Migration scripts and reconciliation reports use these queries to verify that every source item produced the expected set of target items.

Related Objects

The documented relationship data is limited but explicit: OKS_ITEM_SPLIT references OKS_ITEM_SPLIT via SPLIT_ID, and OKS_ITEM_SPLIT is in turn referenced by OKS_ITEM_SPLIT through the same column. This self-referential design is the primary dependency. In a functioning Service Contracts environment, this table operates alongside the broader OKS service contract line and covered-item structures, and its split records are driven by the Service Contracts application logic that performs item splits. When validating or extending integration work, confirm current 12.2.2 column definitions against the live data dictionary, since the ETRM excerpt documents only the ID and SPLIT_ID structure and the self-join relationship.