Search Results okc_outcome_arguments_h




Overview

OKC_OUTCOME_ARGUMENTS_H is a history (audit) table in the OKC — Contracts Core module of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. As its ETRM description states, it is a mirror image of the base table OKC_OUTCOME_ARGUMENTS; the base table carries the detailed column-level semantics, while this "_H" companion preserves prior versions of those rows. In Oracle EBS, the "_H" suffix conventionally denotes a shadow/history table maintained by the application so that amendments to outcome arguments — the parameter values bound to an outcome or rule evaluation within a contract — remain queryable for audit, comparison, and point-in-time reporting.

The ETRM metadata classifies this object heuristically as standalone under Data Vault modeling. Taken as a modeling suggestion, this indicates the table is not a hub or a link in the Data Vault sense: it holds no natural business key of its own and participates in no outgoing parent/child relationships, functioning instead as a versioned satellite of change records tied back to the base contract outcome structures.

Key Information Stored

The table contains 16 documented columns. The most significant are:

  • ID — identifier inherited from the base outcome-argument row; part of the composite primary key.
  • MAJOR_VERSION — version discriminator distinguishing successive historical images of the same logical row; the second component of the primary key.
  • OBJECT_VERSION_NUMBER — optimistic locking counter used by the Contracts framework during concurrent updates.
  • VALUE — the stored argument value captured for this historical version.
  • OCE_ID — reference to the outcome (contract outcome/execution) context owning the argument.
  • PDP_ID — reference to the associated process/rule definition line.
  • AAE_ID — reference to the associated argument/expression entity.
  • DNZ_CHR_ID — contract header/identifier linkage used to scope the argument to a contract.
  • SEEDED_FLAG — indicates whether the row is Oracle-seeded rather than user-defined.
  • SECURITY_GROUP_ID — multi-org/security grouping enforced through the FK to FND_SECURITY_GROUPS.
  • APPLICATION_ID — owning application identifier for the row.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS who-columns describing the audit trail of each version.

The surrogate primary key is OKC_OUTCOME_ARGUMENTS_H_PK, composed of (ID, MAJOR_VERSION). The unique index OKC_OUTCOME_ARGUMENTS_H_U1 covers the same (ID, MAJOR_VERSION) pair, making it the business-key candidate for unique row identification across versions.

Common Use Cases and Queries

Typical usage is historical auditing and reconciliation of contract outcome arguments. Analysts compare current base-table values against prior versions, and audit teams reconstruct what an argument held at a specific effective date.

  • Version history for a logical argument:
    SELECT id, major_version, value, last_updated_by, last_update_date
    FROM   okc.okc_outcome_arguments_h
    WHERE  id = :p_id
    ORDER  BY major_version DESC;
  • Point-in-time reconstruction using the who-columns:
    SELECT *
    FROM   okc.okc_outcome_arguments_h
    WHERE  id = :p_id
    AND    last_update_date <= :as_of_date
    ORDER  BY major_version DESC
    FETCH FIRST 1 ROW ONLY;
  • Detecting changes between current and prior versions by joining the base table to its history on (ID, MAJOR_VERSION) or on ID with MAX(MAJOR_VERSION).
  • Security-scoped reporting constrained by SECURITY_GROUP_ID for multi-org environments.

Because the table is history-only, it is normally queried read-only; direct DML is not supported by the application.

Related Objects

  • OKC_OUTCOME_ARGUMENTS — the base table this history mirrors; join on ID (and MAJOR_VERSION for version alignment).
  • FND_SECURITY_GROUPS — referenced via the FK OKC_OUTCOME_ARGUMENTS_H.SECURITY_GROUP_ID, used for multi-org security filtering.
  • OKC_OUTCOME_ARGUMENTS_H_PK / OKC_OUTCOME_ARGUMENTS_H_U1 — primary key and unique indexes on (ID, MAJOR_VERSION).
  • OKC contract outcome and process definition objects referenced through OCE_ID, PDP_ID, and AAE_ID.
  • DNZ contract header object referenced through DNZ_CHR_ID for contract-level scoping.
  • OKC Contracts Core APIs responsible for maintaining history rows, which should be used instead of direct DML.