Search Results exception_yn




Overview
Explore in AI Chat

Overview

OKC_K_ITEMS_HV is a history view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the OKC — Contracts Core product family and is registered in ETRM with a status of VALID. As its name implies, the view exposes the historical (versioned) record set maintained for contract line items in Oracle Contracts. Its defining characteristic is that it is defined entirely over the history table OKC_K_ITEMS_H rather than the transactional table OKC_K_ITEMS, which means every row represents a stored version of a contract item rather than the single current row.

The view therefore plays a well-defined role in reporting and integration. It allows a query to reconstruct the temporal evolution of a contract line — how an item looked prior to an amendment, what was later superseded, and which version is currently active — without reading audit trail tables or relying on date-effective joins. Because the view carries the full audit column set (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_ID, and related program columns), it also serves as a self-documenting record of who changed a line item and through which concurrent request.

Underlying Base Objects

ETRM documents a single referenced base object for this view: the synonym OKC_K_ITEMS_H, which resolves to the history table of the same name in the APPS schema. The view text is a simple projected SELECT over that table using the alias CIMB. There is no join, no filter, and no aggregation in the definition; the view is effectively a renamed, stable interface to the history table.

This one-to-one relationship has practical consequences. Row counts in the view match row counts in OKC_K_ITEMS_H exactly. Any predicate that would be valid against the base history table is valid here. The view becomes the recommended access path because it insulates external reports and custom code from the physical table name and because it is the object catalogued and supported by ETRM for this purpose. The ROWID of the underlying history row is surfaced under the alias ROW_ID, which preserves the ability to address a specific historical version.

Key Columns

  • ID / MAJOR_VERSION — The surrogate identifier of the contract line item together with the major version number. Together they distinguish a specific stored version of an item.
  • CLE_ID — The contract line (or line entity) identifier to which the item belongs. This is the principal join key back to contract header and line structures.
  • CLE_ID_FOR — The line identifier used for the item's "for" reference, mapping the item to the commercial context for which it is priced or applied.
  • CHR_ID / DNZ_CHR_ID — The contract header identifier and the associated header used to scope item lookups to the correct contract.
  • OBJECT1_ID1 / OBJECT1_ID2 / JTOT_OBJECT1_CODE — The polymorphic reference that identifies the inventory, service, or other object being sold, together with the object type code that determines how the ID columns are interpreted.
  • UOM_CODE, NUMBER_OF_ITEMS, PRICED_ITEM_YN, EXCEPTION_YN — Quantity and pricing attributes of the line item, including unit of measure, quantity, whether the item is priced, and whether it was flagged as an exception.
  • OBJECT_VERSION_NUMBER — The ORM/OC4J optimistic locking column, useful for detecting concurrent modifications in integrations.
  • Audit columns — Standard EBS WHO and concurrent program columns, which in a history view are essential for reconstructing the timeline of changes.

Common Use Cases and Queries

The most frequent use of OKC_K_ITEMS_HV is version-diff reporting: retrieving all versions of the line items on a given contract so that changes over time can be compared, particularly where the "cle_id_for" relationship must be traced between item versions.

SELECT id, major_version, cle_id, cle_id_for, chr_id,
       object1_id1, uom_code, number_of_items,
       last_updated_by, last_update_date
FROM   apps.okc_k_items_hv
WHERE  chr_id = :p_chr_id
ORDER  BY cle_id, id, major_version;

A second common pattern is identifying the currently active version for each item, typically by selecting the maximum major version per ID, and a third is auditing who changed a specific line item within a date range using the LAST_UPDATE_DATE and LAST_UPDATED_BY columns. Because the history table preserves superseded rows, queries against this view must always include a version predicate to avoid returning duplicate logical items.