Search Results multi_mod_request_id

Overview

PO_MULTI_MOD_REQUESTS is the control (header) table for the Multiple Modifications and Supplier Change Requests feature within the Oracle Purchasing (PO) module. In Oracle EBS 12.1.1 and 12.2.2, this object is owned by the PO schema and is documented as VALID in the ETRM repository. It governs the lifecycle of bulk modification requests raised against purchasing documents and supplier records, including mass changes to purchase orders, blanket agreements, contracts, and supplier novations. The table stores the request-level attributes — request type, validation status, approval flags, effective dates, acceptance requirements, and descriptive identifiers — while child tables capture the individual document, clause, and change-line detail.

From a Data Vault modeling perspective, the mined FK structure classifies PO_MULTI_MOD_REQUESTS as a standalone object. Although the heuristic labels it standalone, it functions as a natural hub candidate: it holds a surrogate primary key (MULTI_MOD_REQUEST_ID) that is referenced as a foreign key by four dependent child tables, and its business attributes (request type, status, dates) would typically be modeled as a satellite riding on that hub.

Key Information Stored

The documented physical schema contains 41 columns. The surrogate primary key is MULTI_MOD_REQUEST_ID, defined by the constraint PO_MULTI_MOD_REQUESTS_PK.

• MULTI_MOD_REQUEST_ID — surrogate primary key; the sole PK column.
• MULTI_MOD_REQUEST_TYPE — classifies the request (for example, multiple modification versus supplier change/novation).
• VALIDATION_STATUS and STATUS — validation and workflow/lifecycle state of the request.
• SELECTION_CHANGED_FLAG — indicates whether the selected document set has changed.
• DESCRIPTION — free-text description of the request.
• MOD_EFFECTIVE_DATE and NOVATION_EFFECTIVE_DATE — effective dates for modifications and supplier novations.
• ACCEPTANCE_REQUIRED_FLAG and ACCEPTANCE_DUE_DATE — supplier acceptance tracking.
• INITIATE_APPROVAL_FLAG — whether approval workflow is triggered.
• CLM_CONTRACT_OFFICER and CLM_NOOFCOPIES — contract-lifecycle (CLM) integration attributes.
• UDA_TEMPLATE_ID, UDA_TEMPLATE_DATE, UDA_KEY_PO_HEADER_ID, UDA_KEY_DRAFT_ID — user-defined attribute template context.
• AGENT_ID — the procurement agent associated with the request.
• Audit/WHO columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY, REQUEST_ID, and the ATTRIBUTE_CATEGORY/ATTRIBUTE1–15 descriptive flexfield columns.

No unique business-key index beyond the surrogate PK is documented in the provided metadata; MULTI_MOD_REQUEST_TYPE combined with creation context is the practical business discriminator.

Common Use Cases and Queries

Typical scenarios include auditing open supplier-change requests, tracking validation and approval status, and reporting on pending acceptance obligations.

• Listing active change requests by type and status:

SELECT multi_mod_request_id, multi_mod_request_type, status,
       validation_status, mod_effective_date, agent_id
FROM   po.po_multi_mod_requests
WHERE  status = 'INCOMPLETE'
ORDER BY creation_date DESC;

• Identifying requests still awaiting supplier acceptance:

SELECT multi_mod_request_id, acceptance_due_date, novation_effective_date
FROM   po.po_multi_mod_requests
WHERE  acceptance_required_flag = 'Y'
AND    acceptance_due_date < SYSDATE;

• Correlating a request with its affected documents, clauses, and changes by joining child tables on MULTI_MOD_REQUEST_ID.

Related Objects

Four documented child tables reference this control table through MULTI_MOD_REQUEST_ID:

• PO_MULTI_MOD_DOCS.MULTI_MOD_REQUEST_ID — documents included in the request.
• PO_MULTI_MOD_CHANGES.MULTI_MOD_REQUEST_ID — individual field-level changes.
• PO_MULTI_MOD_CLAUSE_CHANGES.MULTI_MOD_REQUEST_ID — clause modifications.
• PO_MULTI_MOD_VAL_RESULTS.MULTI_MOD_REQUEST_ID — validation outcomes.

These joined objects provide the full modification detail, while PO_MULTI_MOD_REQUESTS supplies the request header context consumed by the Purchasing Multiple Modifications and Supplier Change Request concurrent programs and related PO APIs.