Search Results sav_sae_id




Overview
Explore in AI Chat

Overview

APPS.OKC_K_ATE_V is a reporting and integration view within the Oracle E-Business Suite Contracts (OKC) module, part of the ETRM (Enterprise Contracts) schema family. It consolidates contract header information with the standard articles (clauses, terms, and structured text) attached to those contracts, exposing a flattened and de-normalized result set suitable for direct querying by reports, extracts, and downstream interfaces. Unlike the base transactional tables, which store contract headers, article instances, and article versions in separate structures with surrogate keys, OKC_K_ATE_V joins these structures and presents human-readable identifiers, contract numbers, descriptions, and article identifiers together.

The view is defined with a DISTINCT clause, indicating that the join across headers, articles, and article versions can produce duplicate rows when multiple version records or article instances match the same contract. The DISTINCT suppresses that duplication so that consumers receive one row per contract/standard-article combination. This makes the view particularly convenient for ad-hoc operational reporting without requiring the caller to understand the OKC data model.

Underlying Base Objects

The view is documented as being defined over the following objects:

  • OKC_K_HEADERS_V (VIEW) — the contract header source, aliased as A. Supplies the contract ID, contract number, contract number modifier, and short description.
  • OKC_K_ARTICLES_B (SYNONYM) — the base article table, aliased as B. Supplies the SAV_SAE_ID column, which is the key linkage between a contract and its article.
  • OKC_ARTICLE_VERSIONS (SYNONYM) — the article version table, aliased as VERS. Supplies the version identifier and release information.
  • OKC_ARTICLES_V (VIEW) — the articles view, aliased as ART. Used to confirm the article is the standard version via STANDARD_YN.
  • OKC_UTIL (PACKAGE) — referenced for supporting utility logic associated with the OKC schema.

The join logic links contract headers to articles through DNZ_CHR_ID = A.ID, then joins the article's SAV_SAE_ID to ART.ARTICLE_ID, and finally connects the article version through B.ARTICLE_VERSION_ID = VERS.ARTICLE_VERSION_ID. The predicate ART.STANDARD_YN = 'Y' restricts results to standard articles.

Key Columns

  • ID — the contract header identifier (DNZ_CHR_ID), the primary linkage currency in the OKC model.
  • CONTRACT_NUMBER and CONTRACT_NUMBER_MODIFIER — the user-facing contract number and its optional modifier, together forming the contract reference.
  • SHORT_DESCRIPTION — a brief textual description of the contract.
  • SAV_SAE_ID — the article identifier exposed from OKC_K_ARTICLES_B. This is the column the user searched for and represents the article/SAE reference attached to the contract.
  • SAV_SAV_RELEASE — the release or version value, computed as NVL(VERS.SAV_RELEASE, VERS.ARTICLE_VERSION_NUMBER). This yields the SAV release when populated and falls back to the article version number otherwise.

Common Use Cases and Queries

The view is typically used to report which standard articles and article releases are attached to a given contract. Because SAV_SAE_ID is exposed directly, it is especially useful for identifying contracts associated with a specific article identifier, or for tracing the release lineage of that article across contracts.

A representative query returning all standard articles for a specific contract is:

  • SELECT contract_number, contract_number_modifier, short_description, sav_sae_id, sav_sav_release FROM apps.okc_k_ate_v WHERE id = :contract_id;

To locate contracts tied to a particular article identifier, the SAV_SAE_ID column can be filtered directly:

  • SELECT id, contract_number, sav_sae_id, sav_sav_release FROM apps.okc_k_ate_v WHERE sav_sae_id = :sav_sae_id;

For release-level analysis, the computed SAV_SAV_RELEASE column supports grouping and reporting of article releases across the contract population, for example aggregating counts of contracts per release. Because the view relies on the OKC_UTIL package and the underlying Contracts views, query performance is best when accessed with the Apps schema and appropriate Contracts responsibilities, and callers should expect the DISTINCT processing to carry a modest cost on large contract volumes.