Results for “okc_outcomes_bh”

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

Overview

OKC_OUTCOMES_BH is a history (audit) table within the OKC – Contracts Core module of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. It stores the versioned historical records of the base table OKC_OUTCOMES_B, which holds outcome definitions associated with contract documents. Contract outcomes represent the results, deliverables, or fulfillment conditions tied to a contract line, document, or template. Whenever a row in OKC_OUTCOMES_B is updated, the prior state is preserved in this history table, enabling change tracking, audit compliance, and point-in-time reconstruction of outcome data.

The primary key is OKC_OUTCOMES_BH_PK, defined on (ID, MAJOR_VERSION), and a unique index OKC_OUTCOMES_BH_U1 also exists on (ID, MAJOR_VERSION). The ETRM metadata classifies this object heuristically as standalone in Data Vault terms, meaning it does not itself function as a conventional hub, link, or satellite. From a modeling perspective, the composite key of a persistent business identifier (ID) plus a version discriminator (MAJOR_VERSION) makes it behave like a satellite-style versioned history structure anchored to the underlying outcome entity.

Key Information Stored

The table contains 33 documented columns. The most significant include:

• ID – Surrogate identifier of the outcome; the persistent business key shared with OKC_OUTCOMES_B.
• MAJOR_VERSION – Version number that, combined with ID, uniquely identifies each historical row and forms the primary key.
• PDF_ID – Foreign key linking the outcome to its contract document (PDF) context.
• CNH_ID – Reference to the contract header entity associated with the outcome.
• DNZ_CHR_ID – Denormalized contract header identifier used for efficient querying.
• ENABLED_YN – Flag indicating whether the outcome version was active.
• SUCCESS_RESOURCE_ID – Resource responsible for successful fulfillment of the outcome.
• FAILURE_RESOURCE_ID – Resource associated with outcome failure.
• APPLICATION_ID – Application that owns or created the row.
• SEEDED_FLAG – Indicates whether the outcome is Oracle-seeded or user-defined.
• OBJECT_VERSION_NUMBER – Optimistic locking / concurrency control column.
• SECURITY_GROUP_ID – References FND_SECURITY_GROUPS for multi-tenant data isolation.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard audit "WHO" columns.
• ATTRIBUTE_CATEGORY, ATTRIBUTE1 … ATTRIBUTE15 – DFF (Descriptive Flexfield) columns for extensibility.

The surrogate primary key is the (ID, MAJOR_VERSION) pair. ID alone is the business-key candidate inherited from the base table; the history table adds MAJOR_VERSION to distinguish versions.

Common Use Cases and Queries

Typical usages center on audit trails, version comparison, and as-of reporting. A common pattern retrieves the full version history for a given outcome:

SELECT id, major_version, pdf_id, cnh_id, enabled_yn,
       last_updated_by, last_update_date
FROM   okc.okc_outcomes_bh
WHERE  id = :p_id
ORDER  BY major_version DESC;

Another frequent scenario joins history rows back to the current base record to identify changed attributes between versions, or queries only the latest historical version prior to a cutoff date using LAST_UPDATE_DATE. Reporting extracts often join to OKC_OUTCOMES_B for a complete picture, and to contract header tables via CNH_ID or DNZ_CHR_ID for outcome-by-contract reporting. Because SECURITY_GROUP_ID is present, all queries must respect the security group mechanism in multi-org or multi-tenant deployments.

Related Objects

• OKC_OUTCOMES_B – The base table whose prior versions are archived here; joined on ID (and MAJOR_VERSION).
• OKC_OUTCOMES_BH_PK – Primary key constraint on (ID, MAJOR_VERSION).
• OKC_OUTCOMES_BH_U1 – Unique index on (ID, MAJOR_VERSION).
• FND_SECURITY_GROUPS – Referenced by SECURITY_GROUP_ID foreign key.
• OKC_CONTRACT_HEADERS / DNZ contract tables – Associated through CNH_ID and DNZ_CHR_ID for header context.
• OKC contract document tables (via PDF_ID) – Provide the document-level context of each outcome version.
• FND_APPLICATION – Referenced by APPLICATION_ID.

These relationships make OKC_OUTCOMES_BH a valuable companion for any Contracts Core audit or reporting solution requiring historical outcome visibility.