Search Results oks_inst_hist_details




Overview
Explore in AI Chat

Overview

The OKS_INST_HIST_DETAILS table resides in the OKS schema and belongs to the Service Contracts (OKS) product family within Oracle E-Business Suite, with identical behavior in releases 12.1.1 and 12.2.2. The table functions as an audit and history ledger for changes to installed base instance records maintained in OKS. Each row captures a discrete transaction against an installed base instance — a quantity change, an amount change, a contract reassignment, a service line or subline move, a customer transfer, or a cancellation — recording both the before-image and the after-image of the affected attributes.

Because every row represents a dated event connecting an existing installed base instance to a transformed state, the table behaves as an event or history table rather than a static master record. The mined Data Vault classification from the documented foreign key structure is "standalone," which is a reasonable heuristic given that only a single FK (SECURITY_GROUP_ID to FND_SECURITY_GROUPS) is documented. From a modeling standpoint, this table is best treated as a satellite or link capturing versioned history of the OKS installed base instance hub, with TRANSACTION_DATE providing the effective dating. The classification should be regarded as a suggestion, since the true hub-and-link topology emerges only when the table is considered alongside OKS_INSTALLED_BASE and the contract tables it references through surrogate IDs.

Key Information Stored

The table carries 42 documented columns. The surrogate primary key is ID, enforced by the constraint OKS_INST_HIST_DETAILS_PK and additionally supported by the unique index OKS_INST_HIST_DETAILS_U1 (ID). There is no separate business-key composite documented beyond ID, so the surrogate key is the sole reliable unique identifier for a history row.

Common Use Cases and Queries

The most common requirement is point-in-time reconstruction of an instance's contract, service line, quantity, or customer state. A typical query filters by INS_ID and orders by TRANSACTION_DATE to produce a change timeline:

  • Instance change history: SELECT transaction_date, transaction_type, instance_qty_old, instance_qty_new FROM oks_inst_hist_details WHERE ins_id = :ins_id ORDER BY transaction_date.
  • Contract transfer audit: filter where OLD_CONTRACT_ID or NEW_CONTRACT_ID equals a contract, to trace instances moving onto or off a contract.
  • Cancellation and termination reporting: rows where DATE_CANCELLED or SUBLINE_DATE_TERMINATED is populated.
  • Quantity and value reconciliation: comparing INSTANCE_QTY_OLD/NEW and INSTANCE_AMT_OLD/NEW to validate billing or entitlement changes.
  • Customer transfer analysis: grouping on OLD_CUSTOMER and NEW_CUSTOMER to detect ownership shifts.

Related Objects

The documented relationship set is intentionally narrow. The single documented foreign key is OKS_INST_HIST_DETAILS.SECURITY_GROUP_ID referencing FND_SECURITY_GROUPS, which enforces multi-org style data segregation. The principal logical parents — OKS_INSTALLED_BASE via INS_ID, and the contract, service line, and subline tables referenced through the OLD_/NEW_ surrogate columns — should be joined explicitly in reporting. Supporting audit references include FND_USER for CREATED_BY and LAST_UPDATED_BY lookups. Because the security group column is the only enforced FK, referential integrity to the installed base and contract entities is maintained by the application layer, and joins should be validated against OKS_INSTALLED_BASE and the OKS contract tables when building historical reports.