Search Results oks_interaction_history




Overview
Explore in AI Chat

Overview

The OKS_INTERACTION_HISTORY table resides in the OKS schema and belongs to the Service Contracts (OKS) module of Oracle E-Business Suite. Its documented purpose is to serve as an interaction history table for auto renewal processing. Within the Service Contracts architecture, auto renewal logic operates against contract headers in OKC_K_HEADERS_B; OKS_INTERACTION_HISTORY captures the audit trail of interactions generated during the renewal lifecycle. Each row records a discrete event or attempt associated with a specific contract header, exposing attributes such as renewal status, task name, task result, and the acting user. This makes the table a useful source for diagnostics and operational reporting on automated renewal runs.

From a data modeling perspective, the metadata classifies this object as satellite-leaning under heuristic Data Vault analysis. That classification is a modeling suggestion rather than a physical design statement: the table carries descriptive, time-stamped attributes that depend on a parent business key supplied by OKC_K_HEADERS_B, which aligns with the behavior of a satellite entity surrounding the contract header hub.

Key Information Stored

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

  • ID — the surrogate primary key, enforced by OKS_INTERACTION_HISTORY_PK. It uniquely identifies each interaction record and is the recommended join key when relating history rows to other tables.
  • CHR_ID — the foreign key to OKC_K_HEADERS_B, linking each interaction to its parent contract header. This is the principal business relationship column.
  • CONTRACT_NUMBER and CONTRACT_NUMBER_MODIFIER — the human-readable contract identifier captured at the time of the interaction, useful for reporting without joining to the header table.
  • RENEWAL_STATUS — the state of the auto renewal attempt associated with the interaction.
  • STATUS — the overall status of the interaction record.
  • PARTY_ID — the party associated with the contract interaction.
  • USER_ID — the user responsible for or associated with the interaction.
  • DESCRIPTION — free-form text describing the interaction.
  • TASK_NAME and TASK_RESULT — the auto renewal task executed and its outcome, the core diagnostic fields.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN — standard EBS audit columns that establish when the record was produced and who touched it.
  • OBJECT_VERSION_NUMBER — the optimistic locking column used by the EBS framework.

No secondary unique index on business columns is documented; the surrogate ID remains the only documented unique key.

Common Use Cases and Queries

Typical scenarios include troubleshooting failed or skipped auto renewals, auditing which tasks ran for a given contract, and reporting renewal outcomes by party or user. Because TASK_NAME and TASK_RESULT preserve per-attempt detail, the table supports root-cause analysis of renewal programs.

A representative query isolates recent renewal activity for a contract:

  • SELECT h.ID, h.CHR_ID, h.CONTRACT_NUMBER, h.RENEWAL_STATUS, h.TASK_NAME, h.TASK_RESULT, h.CREATION_DATE FROM OKS_INTERACTION_HISTORY h WHERE h.CHR_ID = :contract_header_id ORDER BY h.CREATION_DATE DESC;
  • Aggregate failures by task: SELECT TASK_NAME, TASK_RESULT, COUNT(*) FROM OKS_INTERACTION_HISTORY WHERE CREATION_DATE >= :start_date GROUP BY TASK_NAME, TASK_RESULT;
  • Join to the contract header for additional attributes: SELECT k.CONTRACT_NUMBER, h.RENEWAL_STATUS, h.TASK_RESULT FROM OKS_INTERACTION_HISTORY h, OKC_K_HEADERS_B k WHERE h.CHR_ID = k.ID;

Related Objects

  • OKC_K_HEADERS_B — the parent contract header table; joined via OKS_INTERACTION_HISTORY.CHR_ID = OKC_K_HEADERS_B.ID. This is the only foreign key documented for the table and the primary relationship to model.
  • OKS_INTERACTION_HISTORY_PK — the primary key constraint on ID, governing uniqueness of interaction records.
  • Additional dependent objects in the OKS Service Contracts module — including auto renewal and contract header inquiry views and concurrent program outputs — consume this table as a history source, though they are not enumerated in the documented metadata.

Oracle EBS 12.1.1 and 12.2.2 share this structure; the documented 12.2.2 schema lists all 17 columns, and any client-side extensions should be applied through standard EBS customization practices rather than direct modification of the OKS-owned table.