Search Results okx_po_req_headers_v

Overview

The OKX_PO_REQ_HEADERS_V view is a Contracts Integration (OKX) reporting object within Oracle E-Business Suite. It presents requisition header information from the purchasing module in a form suited to contract and procurement integration flows, allowing downstream applications and reports to consume a consistent set of requisition attributes without querying the underlying transactional table directly. The view is defined in the ETRM metadata with an Implementation/DBA Data note of "Not implemented in this database," indicating that the definition is documented for reference but is not deployed within the specific environment from which the metadata was extracted. Consequently, the object functions as a documentation artefact as much as a runtime view.

The view is named with the OKX prefix, associating it with the Contracts Integration product family, and maps closely to the standard purchasing requisition header structure. Because the underlying column names mirror those of PO_REQUISITION_HEADERS_ALL, the view is intended to be a transparent, integration-friendly projection of that base table.

Underlying Base Objects

The documented definition selects from a single base object: PO_REQUISITION_HEADERS_ALL, the standard Oracle Purchasing requisition header table. The ETRM metadata records no additional referenced base objects, and the SELECT list contains no joins or subqueries, confirming a straightforward one-to-one projection of header rows.

Two synthetic columns are introduced by the view definition: REQUISITION_HEADER_ID is aliased as ID1, and a constant literal '#' is aliased as ID2. These aliases typically serve the key-flexfield or integration keying conventions used by OKX/ETRM entities, where a composite or surrogate identifier is required. All remaining columns are passed through with names identical to their source columns in PO_REQUISITION_HEADERS_ALL. The "Referenced base objects: none documented" note in the ETRM record reflects a metadata gap rather than the absence of a base table: the view text explicitly names PO_REQUISITION_HEADERS_ALL.

Key Columns

• ID1 — Alias for REQUISITION_HEADER_ID, the primary key of the requisition header and the join key to requisition lines and distributions.
• ID2 — A static literal '#', present to satisfy the identifier pattern expected by the integration framework.
• NAME / SEGMENT1 — The requisition number; both columns expose the same value, with SEGMENT1 also retained under its native name.
• PREPARER_ID — Identifier of the user who prepared the requisition.
• LAST_UPDATE_DATE / LAST_UPDATED_BY — Standard audit columns used for incremental extraction and change tracking.
• CLOSED_CODE — The requisition header closure status. Values follow the CLOSED_CODE lookup (for example OPEN, CLOSED, CLOSED FOR RECEIVING, CLOSED FOR INVOICING, FINALLY CLOSED), and this is the column most relevant to the search term.
• AUTHORIZATION_STATUS — Approval state of the requisition, such as INCOMPLETE, IN PROCESS, APPROVED, REJECTED, or RETURNED.
• TYPE_LOOKUP_CODE — Requisition type, typically PURCHASE or INTERNAL.
• SUMMARY_FLAG / ENABLED_FLAG / START_DATE_ACTIVE / END_DATE_ACTIVE — Key-flexfield descriptive columns carried from the base table.
• NOTE_TO_AUTHORIZER / DESCRIPTION — Free-text attributes of the requisition header.
• ORG_ID — Operating unit identifier, essential for multi-org security and filtering.
• APPS_SOURCE_CODE — Source system or application code associated with the requisition.

Common Use Cases and Queries

The primary use case is the extraction of requisition header data into contract and procurement integrations, filtered by operating unit, closure status, or audit timestamp. Because CLOSED_CODE is exposed directly, reporting on requisitions that remain open versus those finally closed is straightforward.

Example: list approved, still-open requisitions for one operating unit.

SELECT id1,
       segment1        AS requisition_number,
       preparer_id,
       authorization_status,
       closed_code,
       org_id,
       last_update_date
FROM   okx_po_req_headers_v
WHERE  org_id = :p_org_id
AND    authorization_status = 'APPROVED'
AND    closed_code = 'OPEN';

Example: incremental extract of headers changed since a given date, used to feed a contract staging table.

SELECT id1, segment1, description, type_lookup_code,
       closed_code, apps_source_code, last_update_date
FROM   okx_po_req_headers_v
WHERE  last_update_date >= :p_last_run
ORDER  BY last_update_date;

Example: closure status summary by operating unit.

SELECT org_id, closed_code, COUNT(*) req_count
FROM   okx_po_req_headers_v
GROUP  BY org_id, closed_code;

Where the view is not implemented in the database, as noted in the metadata, equivalent queries must be directed at PO_REQUISITION_HEADERS_ALL using the same column names, substituting REQUISITION_HEADER_ID for ID1.