Search Results po_multi_mod_docs

Overview

PO_MULTI_MOD_DOCS is a transactional table in the Oracle Purchasing (PO) schema that stores the individual documents selected for a Multiple Modifications Request. In Oracle EBS 12.1.1 and 12.2.2, the Multiple Modifications feature allows a buyer or purchasing administrator to apply a single change (for example, a price update, quantity revision, or supplier change) across many purchase orders or releases in one consolidated submission. PO_MULTI_MOD_DOCS serves as the association layer between a modification request header and each affected document, and it also records the draft version of each document generated as part of the modification process. The object status is VALID, with the owner schema PO and primary key PO_MULTI_MOD_DOCS_PK on MULTI_MOD_DOC_ID.

From a Data Vault modeling perspective, the mined foreign-key structure suggests a link classification: the table primarily records associations between a multiple modification request and the purchase documents (and drafts) it affects. A complementary satellite treatment is reasonable for the status and audit columns carried on the same row. This classification is a heuristic modeling suggestion rather than a property of the EBS table itself.

Key Information Stored

The documented physical schema contains eleven columns. The most significant are:

• MULTI_MOD_DOC_ID — Surrogate primary key (PO_MULTI_MOD_DOCS_PK); uniquely identifies each document row within a modification request.
• MULTI_MOD_REQUEST_ID — Foreign key to PO_MULTI_MOD_REQUESTS, linking the row to its parent multiple modifications request.
• DOCUMENT_ID — Identifier of the purchase document (purchase order, release, or similar) included in the request. Combined with MULTI_MOD_REQUEST_ID, this forms the unique business-key candidate PO_MULTI_MOD_DOCS_U1.
• DRAFT_ID — Foreign key to PO_DRAFTS, pointing to the draft version of the document produced or modified during the request.
• STATUS — Processing state of the individual document within the multiple modifications workflow.
• REQUEST_ID — Concurrent request identifier associated with the modification processing.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN capture standard EBS who-did-what-and-when information.

The surrogate key MULTI_MOD_DOC_ID should be distinguished from the business key (MULTI_MOD_REQUEST_ID, DOCUMENT_ID), which the unique index PO_MULTI_MOD_DOCS_U1 enforces to prevent the same document from being added twice to one request.

Common Use Cases and Queries

Typical usage centers on tracking which documents belong to a specific multiple modifications request, monitoring per-document processing status, and joining through to the resulting draft for downstream review.

• List all documents in a given request: SELECT DOCUMENT_ID, STATUS, DRAFT_ID FROM PO_MULTI_MOD_DOCS WHERE MULTI_MOD_REQUEST_ID = :request_id;
• Count documents per request for throughput reporting: group by MULTI_MOD_REQUEST_ID on PO_MULTI_MOD_DOCS.
• Join to PO_MULTI_MOD_REQUESTS for request-level attributes, and to PO_DRAFTS via DRAFT_ID to inspect draft content or change orders.
• Identify failed or incomplete rows by filtering on STATUS, then correlate with PO_MULTI_MOD_VAL_RESULTS to see validation outcomes.

Related Objects

• PO_MULTI_MOD_REQUESTS — Parent header table; joined on MULTI_MOD_REQUEST_ID.
• PO_DRAFTS — Draft document store; joined on DRAFT_ID.
• PO_MULTI_MOD_VAL_RESULTS — Validation results; references PO_MULTI_MOD_DOCS via MULTI_MOD_DOC_ID.
• PO_HEADERS_ALL — Purchase order headers underlying each DOCUMENT_ID.
• PO_LINES_ALL and PO_LINE_LOCATIONS_ALL — Line and shipment detail for the changed documents.
• FND_CONCURRENT_REQUESTS — Concurrent request context via REQUEST_ID.
• PO_MULTI_MOD_DOCS_PK / PO_MULTI_MOD_DOCS_U1 — Primary key and unique index constraints governing row identity.