Search Results po_requisition_headers_clm_v

Overview

APPS.PO_REQS_IN_POOL_SEC_V is a security-enabled read-only database view in the Oracle E-Business Suite Purchasing module. Its purpose is to expose requisition header information exclusively for those requisition headers that currently have one or more lines assigned to the "requisition pool." The requisition pool is the shared staging area from which purchasing agents draw demand during the Buyer's Work Center automatic sourcing process. Because the view filters on the pool participation flag at the line level, it presents only requisitions that are candidates for pooling, sourcing, and subsequent automatic creation of purchase orders.

The view is classified as a security view, a naming convention Oracle applies to objects that limit data visibility based on the operating units a responsibility is permitted to access. This makes it suitable for use inside the Buyer's Work Center, iSupplier, and custom extensions where a restricted, pool-relevant subset of requisition headers is required. The view carries no data of its own; it is a projection over existing requisition and requisition line data.

Underlying Base Objects

The documented base objects referenced by this view are:

• PO_REQUISITION_HEADERS_CLM_V (VIEW) — the primary source of header attributes. This object is aliased as PRH in the view definition and supplies all projected header columns, including ORG_ID, REQUISITION_HEADER_ID, SEGMENT1, DESCRIPTION, and the various status and sourcing columns.
• PO_REQUISITION_LINES (SYNONYM) — referenced inside a correlated EXISTS subquery, aliased as PRL. The subquery matches on REQUISITION_HEADER_ID and restricts to rows where REQS_IN_POOL_FLAG = 'Y'.

The relationship is a semi-join: for each header returned by the header view, the EXISTS clause verifies that at least one associated requisition line is flagged as residing in the pool. Headers without any pooled lines are excluded. Because the header source is itself a view, the underlying repository tables are abstracted, and the security filter is applied at the header view level before the pool predicate is evaluated.

Key Columns

• ORG_ID — operating unit identifier, the basis for multi-org security filtering.
• REQUISITION_HEADER_ID — primary key of the requisition header; used as the join key to lines, distributions, and downstream documents.
• REQUISITION_NUM (SEGMENT1) — the user-visible requisition number.
• DESCRIPTION — free-text description of the requisition header.
• AUTHORIZATION_STATUS — approval state of the requisition (for example, IN PROCESS, APPROVED, REJECTED, PRE-APPROVED, RETURNED).
• CLOSED_CODE — indicates whether the requisition or its lines are open, closed, or finally closed.
• EMERGENCY_PO_NUM / EMERGENCY_PO_ORG_ID — reference to an emergency purchase order created against the requisition, where applicable.
• PCARD_ID — procurement card identifier associated with the requisition, relevant to p-card settlement workflows.
• APPS_SOURCE_CODE — identifies the originating application or source of the requisition (for example, iProcurement, Purchasing).
• PREPARER_ID — the user who prepared the requisition.
• PAR_DRAFT_ID — identifier linking the requisition to the Procurement Public API / draft structure used in the Buyer's Work Center.

Common Use Cases and Queries

Typical uses include identifying pool-eligible requisitions for a given operating unit, feeding the Buyer's Work Center sourcing logic, and supporting custom reporting on requisitions awaiting auto-sourcing. A representative query is:

• List approved, open pool requisitions for an operating unit:

  SELECT requisition_num, description, authorization_status, closed_code
  FROM   apps.po_reqs_in_pool_sec_v
  WHERE  org_id = :p_org_id
  AND    authorization_status = 'APPROVED';

• Drill from a header to its pooled lines on the requisition number:

  SELECT v.requisition_num, l.line_num, l.item_description
  FROM   apps.po_reqs_in_pool_sec_v v,
         apps.po_requisition_lines l
  WHERE  l.requisition_header_id = v.requisition_header_id
  AND    l.reqs_in_pool_flag = 'Y';

• Aggregate pooled demand count by operating unit for backlog analysis:

  SELECT org_id, COUNT(*) pool_req_count
  FROM   apps.po_reqs_in_pool_sec_v
  GROUP  BY org_id;

Because access is governed by the security logic inherited from PO_REQUISITION_HEADERS_CLM_V, query results are automatically limited to the operating units available to the querying responsibility, which is a key advantage over querying repository tables directly.