Search Results po_document_headers_view

Overview

PO_DOCUMENT_HEADERS_VIEW is an APPS-owned database view in the Oracle E-Business Suite Purchasing (PO) module. It consolidates header-level information from three distinct purchasing entities — purchase requisitions, purchase orders, and purchase order releases — into a single, uniformly structured result set. The view is defined as the UNION of three SELECT statements, each sourced from a different base table, allowing reporting tools, forms, and integration interfaces to retrieve document header data across the entire procurement document lifecycle without joining each source table individually.

Because purchase orders, blanket agreements, contracts, and their releases are all stored in the same PO_HEADERS / PO_RELEASES structures while requisitions reside in PO_REQUISITION_HEADERS, the view provides a normalized projection that abstracts these physical differences. This makes it particularly valuable for cross-document reporting and for user-facing inquiries that must present a unified list of purchasing documents.

Underlying Base Objects

The view is defined over the following documented base objects:

• PO_REQUISITION_HEADERS — supplies requisition header rows in the first UNION branch.
• PO_HEADERS — supplies purchase order, blanket, contract, and planned order header rows in the second UNION branch.
• PO_RELEASES — supplies release header rows in the third UNION branch; the release segment is concatenated as PO_HEADERS.SEGMENT1 || '-' || PO_RELEASES.RELEASE_NUM.
• PO_DOCUMENT_TYPES_ALL_B and PO_DOCUMENT_TYPES_ALL_TL — provide the translated document type name (TYPE_NAME) and enforce the correct document type/subtype mapping for each branch. The _TL join is filtered by USERENV('LANG') and ORG_ID.
• PO_EMPLOYEES_SV — a PL/SQL package whose GET_EMP_NAME function resolves the preparer or agent name from the preparer/agent ID.
• PO_HEADERS_ALL — referenced as part of the PO_HEADERS synonym chain for the underlying header data.

Each UNION branch reconciles the source table against the document types setup tables, ensuring that only valid document type/subtype combinations are returned.

Key Columns

The view projects a common set of columns across all three branches:

• Document identifier — the primary key of the source record (REQUISITION_HEADER_ID, PO_HEADER_ID, or PO_RELEASE_ID).
• Document category — a literal value of 'REQUISITION', 'RELEASE', or a type-derived code ('PO' or 'PA') that classifies the row.
• Document type / subtype — the type lookup code (for example STANDARD, BLANKET, CONTRACT, PLANNED) and the derived document type code.
• SEGMENT1 — the document number; for releases this is the concatenated PO number and release number.
• REVISION_NUM — the revision, defaulted to 0 via NVL where null; requisitions carry a TO_NUMBER('0') placeholder.
• TYPE_NAME — the translated document type description from PO_DOCUMENT_TYPES_ALL_TL.
• Preparer/agent name and ID — resolved through PO_EMPLOYEES_SV.GET_EMP_NAME.
• CREATION_DATE, DESCRIPTION/COMMENTS, NOTE_TO_AUTHORIZER — descriptive attributes.
• ORG_ID — the operating unit, used throughout to scope the document type setup joins.

Common Use Cases and Queries

The view is commonly used to drive unified document searches, dashboards, and integration extracts. A user searching for "po_releases" will find that releases appear here alongside their parent purchase orders, enabling a single query to return both.

Example — list all document headers for an operating unit:

• SELECT document_category, segment1, type_name, preparer_name, creation_date FROM po_document_headers_view WHERE org_id = :org_id ORDER BY creation_date DESC;

Example — retrieve all releases with their parent PO number encoded in SEGMENT1:

• SELECT segment1, type_name, agent_name FROM po_document_headers_view WHERE document_category = 'RELEASE';

Example — locate requisitions by preparer:

• SELECT segment1, description, preparer_name FROM po_document_headers_view WHERE document_category = 'REQUISITION' AND preparer_id = :preparer_id;

Because it performs UNION operations across large header tables, queries should always filter on ORG_ID, CREATION_DATE, or document identifiers to control execution cost. The view is read-only and intended for inquiry and reporting rather than transactional updates.