Search Results archived_yn




Overview
Explore in AI Chat

Overview

APPS.OE_BLANKET_VERSIONS_V is a reporting view in the Oracle E-Business Suite Order Management (OE) module that consolidates the version history of blanket sales agreements. In Oracle EBS 12.1.1 and 12.2.2, blanket agreements can carry multiple versions as terms are renegotiated, re-approved, or re-signed. The view provides a single, uniform result set that exposes both the currently active version (held in the operational blanket header table) and prior versions retained in the history table, tagging each row with an ARCHIVED_YN flag to distinguish the two. This makes it a convenient source for inquiry screens, version-comparison reports, and integration interfaces that must present a customer's full blanket agreement lineage rather than just the current record.

Underlying Base Objects

The view is defined as a UNION of two synonyms, OE_BLANKET_HEADERS_ALL and OE_BLANKET_HEADERS_HIST, both owned by and resolved in the APPS schema. The first branch selects from OE_BLANKET_HEADERS_ALL and hard-codes ARCHIVED_YN as 'N', representing the live blanket header. The second branch selects from OE_BLANKET_HEADERS_HIST, filtered by VERSION_FLAG = 'Y', and hard-codes ARCHIVED_YN as 'Y', representing superseded versions moved to history. The VERSION_FLAG predicate restricts the historical branch to rows explicitly flagged as version records. Because the view is read-only and simply projects columns from these two tables, it inherits their security and multi-org characteristics; the caller's operating unit context and MO: Security profile determine which blanket headers are visible.

Key Columns

  • HEADER_ID — Primary identifier of the blanket header record in each source table. Note that the same logical agreement may appear with different HEADER_ID values across the archive and current branches.
  • SALES_DOCUMENT_TYPE_CODE — Identifies the document classification (for example, blanket sales agreement) for the version row.
  • VERSION_NUMBER — The version sequence for the blanket agreement. The view is ordered by VERSION_NUMBER DESC, so the most recent version appears first.
  • SIGNED_YN — Derived via DECODE(NVL(TO_CHAR(CUSTOMER_SIGNATURE_DATE), 'N'), 'N', 'N', 'Y'). It evaluates to 'Y' when a customer signature date exists on the version, otherwise 'N'.
  • ARCHIVED_YN — The column most relevant to the "archived_yn" search. It is 'N' for rows drawn from the current blanket header table and 'Y' for rows drawn from the history table, enabling callers to filter current versus superseded versions in a single query.

Common Use Cases and Queries

The dominant use case is retrieving the complete version audit trail of a blanket agreement, including which versions are archived and which remain active. A typical query returns all versions for a specific agreement or across agreements, ordered newest-first:

SELECT header_id, sales_document_type_code, version_number,
       signed_yn, archived_yn
  FROM apps.oe_blanket_versions_v
 WHERE archived_yn = 'N'
 ORDER BY version_number DESC;

Filtering ARCHIVED_YN = 'Y' isolates historical versions for audit or comparison reporting, while omitting the predicate on ARCHIVED_YN yields the full lineage. Because SIGNED_YN is exposed directly, reporting on signature compliance is straightforward, for example counting unsigned current versions with WHERE signed_yn = 'N' AND archived_yn = 'N'. Integrations that publish blanket version status to external systems commonly SELECT the projection above and key on HEADER_ID combined with SALES_DOCUMENT_TYPE_CODE. As with any APPS view, queries should be run in the appropriate operating unit context so that multi-org security filters apply correctly.