Results for “authorization_status”

50+ results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The APPS.PO_REQS_IN_POOL_SEC_V view is a Purchasing (PO) module security view shipped in Oracle E-Business Suite 12.1.1 and 12.2.2. It was created specifically to support the HTML Autocreate feature, presenting the set of requisition headers that contain at least one line currently sitting in the Autocreate pool — that is, lines eligible for automatic conversion into purchase orders. Critically, the view restricts results to the operating units granted to the current user through the MO: Security Profile, making it the requisition-side companion to the pool line security views used during the Autocreate flow.

In the context of Oracle EBS reporting and integration, this view exposes a pre-joined, security-filtered requisition header projection. Rather than requiring report authors or integrations to reproduce the multi-org security logic and the pool-membership join independently, the view encapsulates both, returning only the requisition headers that are actionable by the signed-in user. This makes it suitable for HTML-based Autocreate pages, custom dashboards, and any extension that must surface "requisitions ready to autocreate" without violating operating unit access rules.

Underlying Base Objects

Per the ETRM 12.2.2 metadata, the view is owned by APPS and is defined over the documented base objects PO_REQUISITION_HEADERS_CLM_V (a view) and PO_REQUISITION_LINES (a synonym). The header attributes are sourced from the requisition headers entity, while the pool membership test is applied against the requisition lines.

The documented view text confirms this structure: it selects from PO_REQUISITION_HEADERS_ALL PRH and applies an EXISTS subquery against the pool line security view:

  • Outer query: PO_REQUISITION_HEADERS_ALL PRH — the requisition header driving the row.
  • Correlated EXISTS: PO_REQ_LINES_IN_POOL_SEC_V PRLIP, joined on PRLIP.REQUISITION_HEADER_ID = PRH.REQUISITION_HEADER_ID, testing for "LINES IN THE POOL FROM THE ALLOWED OPERATING UNITS."

This design delegates pool eligibility and MO: Security Profile enforcement to the line-level pool view, so the header view inherits the same operating unit restrictions. A requisition header appears only if it has one or more qualifying pool lines within the user's permitted operating units.

Key Columns

The documented column list is as follows:

  • ORG_ID — Operating unit identifier of the requisition header; the primary multi-org discriminator.
  • REQUISITION_HEADER_ID — Unique surrogate key for the requisition header; the join key to lines and distributions.
  • REQUISITION_NUM — The user-facing requisition number (SEGMENT1 from the header), displayed in Autocreate and reports.
  • DESCRIPTION — Free-text description of the requisition header.
  • AUTHORIZATION_STATUS — Header approval status (e.g., APPROVED, IN PROCESS, REJECTED, PRE-APPROVED), gating whether lines can be autocreated.
  • CLOSED_CODE — Indicates whether the requisition header is open, closed, or finally closed.
  • EMERGENCY_PO_NUM and EMERGENCY_PO_ORG_ID — Emergency PO reference and its operating unit, where applicable.
  • PCARD_ID — Procurement card identifier associated with the requisition, if any.
  • APPS_SOURCE_CODE — Source system/application code identifying the originating application of the requisition.
  • PREPARER_ID — The user identifier of the requisition preparer.

Common Use Cases and Queries

Typical scenarios include HTML Autocreate header listing, custom "ready to autocreate" dashboards, and diagnostic checks of pool membership by operating unit. Because the view already applies MO: Security Profile filtering, queries do not need to join PO_REQUISITION_HEADERS_ALL directly or re-implement org security.

List headers by operating unit with approval status:

  • SELECT org_id, requisition_num, authorization_status, preparer_id FROM apps.po_reqs_in_pool_sec_v WHERE authorization_status = 'APPROVED' ORDER BY requisition_num;

Count pool-eligible requisitions per operating unit:

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

Identify emergency or pcard-sourced requisitions in the pool:

  • SELECT requisition_header_id, requisition_num, emergency_po_num, pcard_id FROM apps.po_reqs_in_pool_sec_v WHERE emergency_po_num IS NOT NULL OR pcard_id IS NOT NULL;

Drill from header to the underlying pool lines for a specific requisition:

  • SELECT h.requisition_num, h.org_id FROM apps.po_reqs_in_pool_sec_v h WHERE h.requisition_header_id = :req_header_id; then join the returned header ID to PO_REQ_LINES_IN_POOL_SEC_V to enumerate eligible lines.

Because results are implicitly scoped to the session's MO: Security Profile, the same SQL returns different row sets for different responsibilities or users. Reports should therefore not hard-code operating unit predicates unless cross-org visibility is intentionally controlled via the security profile. For diagnostics, the view's dependence on PO_REQ_LINES_IN_POOL_SEC_V means a header disappears when all its lines leave the pool or fall outside the allowed operating units.