Search Results po_req_headers_trx_v

Overview

The PO_REQ_HEADERS_TRX_V view, owned by the APPS schema in Oracle E-Business Suite (available in both release 12.1.1 and 12.2.2), exposes requisition header information from the Purchasing (PO) module. It functions as a transactional reporting interface over approved requisition headers, filtering the underlying data to present only the current, active version of each requisition. The suffix "TRX" signals that the view is intended for transactional reporting and integration scenarios rather than for maintenance of draft, working-copy requisition rows.

Because the view is a thin projection over a single base table, it inherits the column structure of PO_REQUISITION_HEADERS while applying a single, business-critical restriction. This makes it a convenient entry point for reports, interfaces, and concurrent programs that require a clean set of requisition header records without having to replicate the conformance-filtering logic themselves.

Underlying Base Objects

The view is defined over the base object PO_REQUISITION_HEADERS (documented as a synonym in the ETRM metadata). The SELECT list reproduces virtually every column of that table and applies the predicate:

• WHERE PRH.CONFORMED_HEADER_ID IS NULL

In the requisition amendment and conformance model, a requisition header is conformed when it has been altered in a way that produces a revised version. The original, approved requisition row retains a null CONFORMED_HEADER_ID, while conformed or superseded versions carry a populated value that references the row they replaced. By filtering on CONFORMED_HEADER_ID IS NULL, the view returns only the live, currently effective header for each requisition, excluding historical or superseded versions.

Key Columns

• REQUISITION_HEADER_ID – Primary key linking the header to requisition lines.
• SEGMENT1–SEGMENT5 – Descriptive flexfield and requisition numbering segments.
• PREPARER_ID – The user who created the requisition.
• AUTHORIZATION_STATUS – Approval state (e.g., APPROVED, IN PROCESS, REJECTED).
• TYPE_LOOKUP_CODE – Requisition type (Purchase, Internal, etc.).
• ORG_ID – Operating unit, essential for multi-org (MOAC) security.
• AMENDMENT_TYPE, AMENDMENT_STATUS, AMENDMENT_REASON – Characterize amendment activity on the requisition.
• REVISION_NUM – Revision counter associated with amendment processing.
• CONFORMED_HEADER_ID – Present in the projection but always null in the result set due to the filter; references the superseded header in the base table.
• APPROVED_DATE, FIRST_APPROVER_ID, FIRST_POSITION_ID – Approval routing metadata.
• WF_ITEM_TYPE, WF_ITEM_KEY – Workflow identifiers for the approval process.
• CLOSED_CODE – Indicates whether the requisition is open or closed.
• ATTRIBUTE1–ATTRIBUTE15, ATTRIBUTE_CATEGORY – Descriptive flexfield storage.
• INTERFACE_SOURCE_CODE, INTERFACE_SOURCE_LINE_ID – Origin of externally loaded requisitions.

Given that the user searched for "amendment_type," it is worth noting that AMENDMENT_TYPE and its companion columns (AMENDMENT_STATUS, AMENDMENT_REASON, REVISION_NUM, CONFORMED_HEADER_ID) are all exposed here, so the view supports amendment-aware reporting directly.

Common Use Cases and Queries

Typical uses include requisition status reports, approval tracking dashboards, and integration extracts. A simple query to list approved requisitions for an operating unit follows:

• SELECT requisition_header_id, segment1, preparer_id, authorization_status, amendment_type, revision_num, approved_date FROM po_req_headers_trx_v WHERE org_id = :p_org_id AND authorization_status = 'APPROVED';

To analyze amendment activity, filter on the amendment columns:

• SELECT segment1, amendment_type, amendment_status, amendment_reason, revision_num FROM po_req_headers_trx_v WHERE amendment_type IS NOT NULL;

Because the view excludes conformed (superseded) headers, it is the preferred source whenever only the effective requisition version is required, avoiding duplicate rows that would otherwise appear when joining to requisition lines.