Search Results po_requisition_headers_pk

Overview

PO_REQUISITION_HEADERS_ALL is the core header-level table in the Oracle Purchasing (PO) module of Oracle E-Business Suite, storing one row per purchase requisition header. It is owned by the PO schema and exists in both 12.1.1 and 12.2.2, where it is a VALID dictionary object. A purchase requisition represents an internal request to procure goods or services before a formal purchase order is created, and this table captures the identity, status, approval state, and organizational context of that request. It sits at the top of the requisition data model, with requisition lines held in PO_REQUISITION_LINES_ALL and distributions attached beneath those lines. Because requisitions feed sourcing, approval workflows, purchase order autocreation, and supplier notifications, this table is a central transactional hub rather than a transactional detail store.

From a Data Vault modeling perspective, the mined foreign-key structure suggests classifying this object as a hub. Its surrogate primary key, REQUISITION_HEADER_ID, is referenced by numerous dependent objects, confirming its role as a stable business entity anchor from which satellites and links would normally be derived.

Key Information Stored

The table contains 94 documented columns. The following are the most operationally significant:

• REQUISITION_HEADER_ID — the surrogate primary key, enforced by PO_REQUISITION_HEADERS_PK. It is the join key to virtually all child tables.
• SEGMENT1 — the user-visible requisition number; part of the unique index PO_REQUISITION_HEADERS_U1 alongside ORG_ID and REVISION_NUM, making it a business-key candidate.
• ORG_ID — the operating unit that owns the requisition, essential for multi-org data security and reporting.
• PREPARER_ID — the person who created the requisition.
• AUTHORIZATION_STATUS — the approval state (for example, In Process, Approved, Rejected, Pre-Approved).
• TYPE_LOOKUP_CODE — the requisition type (Purchase, Internal, Emergency, and similar).
• DESCRIPTION — free-text header description.
• NOTE_TO_AUTHORIZER — commentary passed to approvers.
• APPROVED_DATE — timestamp of approval.
• CLOSED_CODE — indicates whether the requisition is open or closed.
• WF_ITEM_TYPE and WF_ITEM_KEY — identify the Oracle Workflow process instance driving approval.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context that created or updated the row.
• INTERFACE_SOURCE_CODE and INTERFACE_SOURCE_LINE_ID — traceability back to the originating interface or external system.
• REVISION_NUM, AMENDMENT_TYPE, AMENDMENT_STATUS — change-control attributes for revised requisitions.
• Descriptive flexfield columns (ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15) and the SECMENT2–SEGMENT5 key flexfield segments.

Common Use Cases and Queries

Typical reporting and integration scenarios include open requisition listings, approval aging analysis, spend-by-operating-unit reporting, and requisition-to-PO conversion tracking.

• Open requisitions by operating unit:

  SELECT prh.segment1, prh.description, prh.authorization_status,
         prh.approved_date, prh.preparer_id
  FROM   po_requisition_headers_all prh
  WHERE  prh.org_id = :p_org_id
  AND    prh.closed_code = 'OPEN';
  

• Header-to-line detail for a given requisition:

  SELECT prh.segment1, prl.line_num, prl.item_description, prl.quantity
  FROM   po_requisition_headers_all prh,
         po_requisition_lines_all  prl
  WHERE  prh.requisition_header_id = prl.requisition_header_id
  AND    prh.segment1 = :p_req_number;
  

• Approval workload and aging, joining to workflow context through WF_ITEM_KEY.
• Interfacing inbound requisitions using PO_REQUISITIONS_INTERFACE_ALL and correlating results back on REQUISITION_HEADER_ID.
• Purging and archival analysis via PO_PURGE_REQ_LIST to identify candidates for removal.

Because REQUISITION_HEADER_ID is the pivot for every child table, most custom queries should begin with this table and join outward rather than querying children independently.

Related Objects

The documented foreign-key relationships identify the following primary dependents:

• PO_REQUISITION_LINES_ALL — the requisition line detail, joined on REQUISITION_HEADER_ID.
• PO_ACTION_HISTORY — audit and approval history, where OBJECT_ID references the requisition header.
• PO_NOTIFICATIONS_ALL — workflow notifications tied to the requisition, joined on OBJECT_ID.
• PO_PURGE_REQ_LIST — purge staging, joined on REQUISITION_HEADER_ID.
• PO_REQUISITIONS_INTERFACE_ALL — open interface staging table, joined on REQUISITION_HEADER_ID.
• OE_DROP_SHIP_SOURCES and SO_DROP_SHIP_SOURCES — drop-ship demand sources referencing REQUISITION_HEADER_ID.
• MTL_SUPPLY and RCV_SUPPLY — supply records linked via REQ_HEADER_ID.
• PO_HISTORY_REQUISITIONS_ALL — archived requisition history, linked on SEGMENT1.
• PON_AWARD_ALLOCATIONS and PON_BACKING_REQUISITIONS — public-sector sourcing objects referencing ORIG_REQ_HEADER_ID and REQUISITION_HEADER_ID respectively.
• MTL_KANBAN_CARD_ACTIVITY — kanban replenishment activity referencing DOCUMENT_HEADER_ID.

Application programming interfaces such as the Requisition Import concurrent program and the PO Requisition public APIs write to this table, reinforcing its role as the authoritative requisition hub.