Results for “pos_po_revisions_header_v”

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

Overview

The view POS_PO_REVISIONS_HEADER_V is an Oracle E-Business Suite database object owned by the APPS schema and delivered as part of the POS – iSupplier Portal product module. It is a lightweight, DISTINCT projection over the temporary revisions view POS_PO_REVISIONS_TEMP_V, and it serves as a header-level access point for purchase order revision data surfaced through the iSupplier Portal. The view exposes only three columns — LINE_SEQ, HEADER_ID, and RELEASE_ID — which together identify the header context of a purchase order or release under revision.

Its principal role is to supply iSupplier Portal revision-processing logic and dependent reports with a deduplicated set of revision header identifiers. Because revisions in the iSupplier Portal flow are staged in a temporary view before being finalized, POS_PO_REVISIONS_HEADER_V provides an intermediary layer that isolates the header-level attributes from the more granular, line-oriented detail held in its underlying temporary view. The DISTINCT operator ensures that repeated staging passes or multi-line revisions do not produce duplicated header rows, which is important when the view feeds into API-driven validation or notification logic.

Underlying Base Objects

The documented dependency list for POS_PO_REVISIONS_HEADER_V references two base objects:

• POS_PO_REVISIONS_TEMP_V (VIEW) — the immediate source from which all three exposed columns are selected.
• POS_GET (PACKAGE) — the iSupplier Portal package that supports retrieval of revision data and is associated with the runtime population of the temporary revisions view.

The definition is deliberately minimal: SELECT DISTINCT LINE_SEQ, HEADER_ID, RELEASE_ID FROM POS_PO_REVISIONS_TEMP_V. This establishes a strict one-to-many lineage — POS_PO_REVISIONS_TEMP_V is the parent object, and POS_PO_REVISIONS_HEADER_V is a distinct-filtered projection of it. No joins to inventory, purchasing, or supplier master tables are performed at this layer, so any enrichment must be carried out by the calling report, concurrent program, or OAF page.

Key Columns

• LINE_SEQ — the line sequence number associated with the revision record. Although the view is oriented toward header-level identification, LINE_SEQ is retained in the projection and participates in the DISTINCT key, meaning a header may appear more than once if multiple line sequences are staged in the temporary view.
• HEADER_ID — the unique identifier of the purchase order or release header in the purchasing schema. This is the primary correlation key used to link the view back to PO_HEADERS_ALL and related header-level tables.
• RELEASE_ID — the identifier for the release (blanket agreement release) associated with the revision, where applicable. This allows the consumer to distinguish standard purchase orders from releases against a blanket or global agreement.

Common Use Cases and Queries

The view is typically consumed when the iSupplier Portal needs to enumerate which headers are currently subject to revision activity, or when a concurrent program must reconcile staged revisions against final header records. A representative query to list distinct revised headers is:

SELECT DISTINCT header_id, release_id FROM apps.pos_po_revisions_header_v;

A second common pattern correlates the view to purchasing header information to obtain supplier and document context:

SELECT v.header_id, v.release_id, v.line_seq, h.segment1 po_number, h.vendor_id
FROM apps.pos_po_revisions_header_v v, apps.po_headers_all h
WHERE v.header_id = h.po_header_id;

Because the view contains only three narrow columns, it performs efficiently as a driving set for downstream joins. Consumers should be aware that the DISTINCT clause applies across LINE_SEQ, HEADER_ID, and RELEASE_ID collectively, so filtering on a single header_id may still return multiple rows. Reports requiring a strict one-row-per-header result should aggregate using GROUP BY header_id or apply MIN/MAX on LINE_SEQ. As the object is defined over temporary staging structures, its contents are transient and should be treated as session- or process-scoped rather than as a persistent historical record of purchase order revisions.