Search Results por_rcv_reqs_order_v

Overview

POR_RCV_REQS_ORDER_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the ICX product family, which covers Oracle iProcurement and the associated self-service requisitioning and receiving interfaces. The view presents requisition header information joined to the downstream purchasing or order documents that were created from those requisitions, together with receiving-relevant distribution quantities and vendor details. Its principal purpose is to support iProcurement and receiving pages and reports that need to display, for a given requisition, the associated purchase order, release, or internal sales order number alongside vendor and total amount details.

The view is defined with a UNION ALL of two branches. The first branch covers externally sourced requisitions flowing into purchase orders, releases, and shipments with receiving routing configured. The second branch covers inventory-sourced requisitions that map to Oracle Order Management sales order headers. This dual construction allows a single query surface to report both procurement-driven and inventory-driven demand from a common structure.

Underlying Base Objects

The documented base objects referenced by the view are: PO_REQUISITION_HEADERS, PO_REQUISITION_LINES, PO_REQ_DISTRIBUTIONS, PO_HEADERS, PO_LINE_LOCATIONS, PO_RELEASES, PO_DISTRIBUTIONS, PO_VENDORS, PO_SYSTEM_PARAMETERS, OE_ORDER_HEADERS, RCV_SHIPMENT_LINES, and HR_ALL_ORGANIZATION_UNITS_TL. All are accessed through APPS synonyms except PO_VENDORS, which is itself a view.

In the purchasing branch, PO_REQUISITION_HEADERS and PO_REQUISITION_LINES supply the requisition identity and line detail, while PO_DISTRIBUTIONS and PO_LINE_LOCATIONS supply ordered, delivered, and cancelled quantities and shipment status. PO_HEADERS and PO_RELEASES provide the document number and release number, PO_VENDORS supplies the vendor name, and the POR_VIEW_REQS_PKG.GET_REQ_TOTAL function returns the requisition total. In the inventory branch, OE_ORDER_HEADERS and PO_SYSTEM_PARAMETERS link the requisition segment to the sales order source, RCV_SHIPMENT_LINES connects receiving activity, and HR_ALL_ORGANIZATION_UNITS_TL supplies the organization (vendor) name.

Key Columns

• REQUISITION_HEADER_ID — Primary key of the requisition header; the join anchor across branches.
• SEGMENT1 — The requisition number as displayed to users.
• DESCRIPTION — Requisition header description.
• PREPARER_ID — Identifier of the user who prepared the requisition.
• TO_PERSON_ID — Requested deliver-to person on the requisition line.
• ORDER_NUM_REL_NUM — Combined document identifier; the PO number concatenated with the release number (separated by a hyphen) in the purchasing branch, or the sales order number in the inventory branch.
• PO_NUMBER — Purchase order number (NULL in the inventory branch).
• ORDER_NUMBER — Sales order number (NULL in the purchasing branch).
• PO_RELEASE_NUMBER — Release number for blanket or scheduled agreements.
• VENDOR — Vendor name from PO_VENDORS, or organization name for inventory-sourced rows.
• CREATION_DATE — Requisition creation date.

Common Use Cases and Queries

The view is typically queried during receiving operations to identify requisition lines with open receiving quantities, and by iProcurement reporting to show requisition-to-order traceability. Because the purchasing branch filters on POLL.RECEIVING_ROUTING_ID = 3 and excludes closed or cancelled shipments, only actively receivable requisitions appear.

SELECT requisition_header_id,
       segment1,
       order_num_rel_num,
       vendor,
       creation_date
FROM   apps.por_rcv_reqs_order_v
WHERE  segment1 = :requisition_number;

To list all open requisitions for a vendor:

SELECT segment1, po_number, po_release_number, creation_date
FROM   apps.por_rcv_reqs_order_v
WHERE  vendor = :vendor_name
AND    po_number IS NOT NULL;

To distinguish inventory-sourced demand, filter on ORDER_NUMBER IS NOT NULL. The view is not updatable and should be treated strictly as a reporting surface; all transactional changes must be directed to the underlying purchasing or order management APIs.