Search Results emergency_po_num




Overview
Explore in AI Chat

Overview

APPS.PO_REQS_IN_POOL_V is a database view owned by the APPS schema in Oracle E-Business Suite, registered under FND Design Data as PO.PO_REQS_IN_POOL_V and reported with VALID status in both ETRM 12.1.1 and 12.2.2. Its documented view type is a supplementary view used to simplify forms coding. This classification is significant: the view exists primarily to support Oracle Purchasing requisition forms rather than as a public reporting interface. Oracle's own documentation explicitly warns that it does not recommend querying or altering data through this view, because its definition may change dramatically in subsequent minor or major releases. Customers and integrators should therefore treat it as non-contractual and subject to change.

Functionally, the view presents a consolidated picture of requisition lines that reside "in pool" — that is, requisition activity that has not been fully placed on a purchase order or otherwise consumed. It exposes identifying and descriptive attributes of the requisition, its authorization and closure status, and several columns related to emergency purchase orders and procurement-card activity. The user search term emergency_po_num maps directly to a column in this view, which is the principal reason the object is relevant to that search.

Underlying Base Objects

Per the documented metadata, PO_REQS_IN_POOL_V is defined over three base objects, all referenced through APPS synonyms: PO_REQUISITION_HEADERS, PO_REQUISITION_LINES_ALL, and PER_ALL_PEOPLE_F. The requisition header table supplies header-level context such as the requisition header identifier, authorization status, closed code, and operating unit. PO_REQUISITION_LINES_ALL supplies line-level detail, including the key flexfield segment (SEGMENT1), line description, and the emergency purchase-order attributes. PER_ALL_PEOPLE_F supplies the requester's full name, resolved as of the appropriate effective date.

The dependency listing states that PO_REQS_IN_POOL_V is not referenced by any other database object, confirming that it sits at the top of its own dependency chain and has no downstream dependents within the ETRM-documented metadata.

Key Columns

  • SEGMENT1 (VARCHAR2, 20) — the key flexfield segment, typically the requisition number displayed to users.
  • REQUISITION_HEADER_ID (NUMBER) — the primary identifier linking the row to PO_REQUISITION_HEADERS and its lines.
  • FULL_NAME (VARCHAR2, 240) — the requester's name from PER_ALL_PEOPLE_F.
  • DESCRIPTION (VARCHAR2, 240) — descriptive text for the requisition or line.
  • AUTHORIZATION_STATUS (VARCHAR2, 25) — approval state of the requisition.
  • CLOSED_CODE (VARCHAR2, 25) — indicates whether the requisition line is open or closed.
  • EMERGENCY_PO_NUM (VARCHAR2, 20) — the emergency purchase order number associated with the requisition.
  • PCARD_ID (NUMBER, 15) — identifier of the procurement card linked to the transaction, where applicable.
  • APPS_SOURCE_CODE (VARCHAR2, 25) — source code identifying the originating application.
  • EMERGENCY_PO_ORG_ID (NUMBER) — the org_id of the operating unit from which EMERGENCY_PO_NUM is derived. The documented note explains that this column completely qualifies EMERGENCY_PO_NUM, and that starting with release FPJ it is possible to create an emergency PO in a different operating unit than the requisition's own.
  • ORG_ID (NUMBER) — the organization identifier used for multi-org security (MOAC) filtering.

Common Use Cases and Queries

The primary documented use case is supporting Oracle Purchasing requisition forms, where the view simplifies joins across headers, lines, and requester information. Reporting use is secondary and should be undertaken with the caveat that the view is unsupported as a stable interface. A typical query filtering on the emergency purchase order number, and qualifying it by operating unit, is:

SELECT segment1,
       requisition_header_id,
       full_name,
       authorization_status,
       closed_code,
       emergency_po_num,
       emergency_po_org_id,
       org_id
FROM   apps.po_reqs_in_pool_v
WHERE  emergency_po_num = :p_emergency_po_num
AND    NVL(emergency_po_org_id, org_id) = :p_org_id;

Because EMERGENCY_PO_NUM is only fully qualified by EMERGENCY_PO_ORG_ID, queries should always constrain both columns. When joining to base tables, REQUSITION_HEADER_ID links back to PO_REQUISITION_HEADERS. For production reporting or integration interfaces, the recommended practice is to reproduce the required logic directly against PO_REQUISITION_HEADERS, PO_REQUISITION_LINES_ALL, and PER_ALL_PEOPLE_F rather than depending on this forms-support view.