Results for “requisition_header_id”

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

Overview

The PO_PURGE_REQ_LIST table is a Purchasing (PO) module data object owned by the PO schema. Its documented description identifies it as holding "requisition candidates for purging" — that is, the set of purchase requisition headers that have been flagged or queued for purge processing by the Oracle EBS Purchasing purge concurrent programs. It acts as a transient working set rather than a master or transactional table: rows are populated as requisitions become eligible for purging and are consumed or cleared as the purge program executes.

In Data Vault modeling terms, the metadata's heuristic classification places this table as satellite-leaning. The table carries its own descriptive and process attributes (purge name, double-check indicator, and concurrent program context columns) while pointing to a single parent business entity through a foreign key. The classification is best treated as a modeling suggestion: the table describes and contextualizes a requisition at a point in its purge lifecycle, rather than establishing a new business key or resolving a many-to-many relationship.

Key Information Stored

The table contains seven documented columns. The single most important is the surrogate primary key:

• REQUISITION_HEADER_ID — The primary key of PO_PURGE_REQ_LIST (PO_PURGE_REQ_LIST_PK) and simultaneously a foreign key to PO_REQUISITION_HEADERS_ALL. It identifies the requisition header being considered for purge. Note that a unique index, PO_PURGE_REQ_LIST_U1, also exists on this column, making it the de facto business-key candidate as well as the surrogate PK.
• PURGE_NAME — The name or label associated with the purge run or purge grouping, used to segregate candidates from different purge executions or parameter sets.
• DOUBLE_CHECK_FLAG — A flag indicating a re-verification or secondary validation step in the purge decision logic; it controls whether a candidate is re-evaluated before final purging.
• REQUEST_ID — The concurrent request identifier of the purge program instance that inserted the row, enabling traceability back to the submission.
• PROGRAM_APPLICATION_ID — The application identifier of the concurrent program that processed the row.
• PROGRAM_ID — The concurrent program identifier.
• PROGRAM_UPDATE_DATE — The timestamp of the last program-driven update to the row, useful for audit and aging analysis of stale candidates.

The absence of a REQUISITION_LINE_ID or similar column reinforces the header-level granularity of this table: one row per requisition header.

Common Use Cases and Queries

Typical use cases center on auditing and troubleshooting the purge process. Administrators want to know which requisitions are currently queued for purging, when they were flagged, and by which concurrent request.

• Listing current purge candidates for a requisition:

SELECT p.PURGE_NAME, p.DOUBLE_CHECK_FLAG, p.REQUEST_ID, p.PROGRAM_UPDATE_DATE FROM PO.PO_PURGE_REQ_LIST p WHERE p.REQUISITION_HEADER_ID = :req_id;

• Identifying stale candidates that have remained queued beyond an expected window:

SELECT p.REQUISITION_HEADER_ID, p.PROGRAM_UPDATE_DATE FROM PO.PO_PURGE_REQ_LIST p WHERE p.PROGRAM_UPDATE_DATE < SYSDATE - 30;

• Grouping candidates by purge run for volume reporting:

SELECT p.PURGE_NAME, COUNT(*) FROM PO.PO_PURGE_REQ_LIST p GROUP BY p.PURGE_NAME;

Joining to PO_REQUISITION_HEADERS_ALL on REQUISITION_HEADER_ID lets reports surface requisition number, preparation date, and status alongside the purge metadata. Because the table is a working set, queries should anticipate high turnover and avoid treating rows as permanent history.

Related Objects

• PO_REQUISITION_HEADERS_ALL — The parent table; joined on PO_PURGE_REQ_LIST.REQUISITION_HEADER_ID = PO_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID. This is the primary relationship documented via foreign key.
• PO_REQUISITION_LINES_ALL — Child of the requisition header; relevant when verifying whether all lines of a header candidate are purge-eligible.
• PO_REQ_DISTRIBUTIONS_ALL — Distribution-level detail referenced indirectly through the requisition header during purge validation.
• PO_HEADERS_ALL / PO_LINES_ALL — Downstream purchasing documents that may determine whether a requisition can be safely purged.
• FND_CONCURRENT_REQUESTS — Joined on REQUEST_ID to resolve the concurrent request that populated each candidate row.
• FND_CONCURRENT_PROGRAMS — Joined on PROGRAM_APPLICATION_ID and PROGRAM_ID to identify the purge program definition.

Together these objects frame the purge lifecycle: candidate selection in PO_PURGE_REQ_LIST, validation against the requisition and downstream document tables, and execution tracing through the FND concurrent manager tables.