Search Results po_multi_mod_changes

Overview

PO_MULTI_MOD_CHANGES is a transactional table in the Oracle Purchasing (PO) module of Oracle E-Business Suite, owned by the PO schema. It stores supplier-related changes captured against a Multiple Modifications Request, allowing users to apply mass updates to purchase orders through the Multi-Organization Modifications functionality. Each row records a single change element—such as a vendor, vendor site, contact, or remit-to address—associated with a parent modification request. The table is classified as VALID in the ETRM data model for both 12.1.1 and 12.2.2, and its documented physical schema in 12.2.2 comprises 19 columns.

From a heuristic Data Vault modeling perspective, PO_MULTI_MOD_CHANGES is best classified as a link object. It does not hold descriptive master attributes of its own; instead, it connects a Multiple Modifications Request (via MULTI_MOD_REQUEST_ID) to before-and-after supplier reference data (OLD_VENDOR_ID, NEW_VENDOR_ID). It therefore functions as an associative entity whose grain is the individual change line of a modification request.

Key Information Stored

The surrogate primary key is MULTI_MOD_CHANGE_ID, enforced by the constraint PO_MULTI_MOD_CHANGES_PK. The foreign key MULTI_MOD_REQUEST_ID references the parent PO_MULTI_MOD_REQUESTS table and represents the business association between a change and its originating request. The most significant columns include:

• MULTI_MOD_CHANGE_ID – surrogate primary key, uniquely identifying each change record.
• MULTI_MOD_REQUEST_ID – foreign key linking the change to its parent Multiple Modifications Request.
• CHANGE_TYPE – categorizes the modification (for example, vendor or vendor site changes).
• OLD_VENDOR_ID / OLD_VENDOR_NAME – the supplier being replaced, holding both the internal vendor identifier and its display name.
• NEW_VENDOR_ID / NEW_VENDOR_NAME – the replacement supplier, again with identifier and name.
• OLD_VENDOR_SITE_ID / NEW_VENDOR_SITE_ID – the prior and replacement supplier sites.
• NEW_VENDOR_CONTACT_ID – the contact associated with the replacement supplier.
• OLD_REMIT_TO_ADDR / NEW_REMIT_TO_ADDR – the previous and replacement remit-to addresses.
• ORG_ID – the operating unit context for the change.
• REQUEST_ID – the concurrent request that generated or processed the change.

Standard audit columns—CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN—support traceability and are populated by the application's WHO columns infrastructure.

Common Use Cases and Queries

The primary use case is auditing and reconciling mass supplier updates applied to purchase orders. Because vendor and vendor site changes carry significant downstream impact on sourcing, tax, and payment processing, administrators frequently query this table to confirm exactly which POs were touched by a given request. A typical reporting pattern joins the change table to the parent request:

• Identify all changes for a specific request: SELECT * FROM po.po_multi_mod_changes WHERE multi_mod_request_id = :request_id;
• Report replacements of a particular supplier: SELECT multi_mod_request_id, old_vendor_name, new_vendor_name FROM po.po_multi_mod_changes WHERE old_vendor_id = :vendor_id;
• Operating-unit scoped audit: filter by org_id to isolate changes within a single business unit.
• Track the concurrent process responsible: query on request_id and correlate with FND_CONCURRENT_REQUESTS.

Analysts also extract these rows to feed downstream reconciliation between Purchasing and Payables, ensuring that remit-to and site changes have propagated correctly.

Related Objects

• PO_MULTI_MOD_REQUESTS – the parent table, joined on MULTI_MOD_REQUEST_ID = MULTI_MOD_REQUEST_ID.
• PO_VENDORS / PO_VENDOR_SITES_ALL – supplier master tables referenced by the OLD_/NEW_VENDOR_ID and site columns.
• PO_HEADERS_ALL – purchase order headers affected by the modification.
• PO_MULTI_MOD_ITEM_CHANGES / PO_MULTI_MOD_PRICE_CHANGES – sibling change tables for item and price modifications.
• FND_CONCURRENT_REQUESTS – correlates REQUEST_ID to the concurrent program execution.