Search Results msc_undo_summary_pk

Overview

MSC.MSC_UNDO_SUMMARY is a table within the Advanced Supply Chain Planning (MSC) product of Oracle E-Business Suite, validated across both 12.1.1 and 12.2.2 releases. It records the summary of changes made to plan output, functioning as the header-level record for undo operations performed against planning results. Each row represents a discrete undo action, capturing metadata such as the affected plan, the source instance, the table modified, the action performed, and a bookmark label. The table is the parent of the undo transaction structure: it groups the individual change rows held in MSC_UNDO_DETAILS under a single UNDO_ID. From a Data Vault modeling perspective, the metadata heuristic classifies this object as hub-leaning. This suggestion reflects the table's role as a durable, keyed anchor around which a satellite of descriptive attributes (creation/update audit columns, action descriptors) could be modeled.

Key Information Stored

The table contains 13 documented columns. The most significant include:

• UNDO_ID — surrogate primary key (MSC_UNDO_SUMMARY_PK); also a documented unique-index business-key candidate via MSC_UNDO_SUMMARY_U1, uniquely identifying each undo summary record.
• PLAN_ID — identifies the plan whose output was changed by the undo.
• SR_INSTANCE_ID — the source (EBS) instance against which the plan data resides.
• TABLE_CHANGED — the planning table that was reversed or updated.
• ACTION — the type of change applied during the undo.
• TRANSACTION_ID — links the undo to the originating transaction.
• BOOKMARK_NAME — a user-defined bookmark label used to identify the saved planning scenario or undo point.
• PARENT_ID — self-referencing or hierarchical link to a related summary record.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Oracle audit columns recording who created and last modified each row and when.

Common Use Cases and Queries

Planners and administrators use this table to audit, report on, and reverse planning changes. Typical scenarios include identifying all undos applied to a given plan, tracing a bookmark to its underlying change set, and reconciling changed tables against the plan output.

List undos for a specific plan:

• SELECT UNDO_ID, PLAN_ID, TABLE_CHANGED, ACTION, LAST_UPDATE_DATE FROM MSC.MSC_UNDO_SUMMARY WHERE PLAN_ID = :plan_id ORDER BY CREATION_DATE DESC;

Resolve a bookmark to its change details:

• SELECT s.UNDO_ID, s.BOOKMARK_NAME, d.* FROM MSC.MSC_UNDO_SUMMARY s JOIN MSC.MSC_UNDO_DETAILS d ON s.UNDO_ID = d.UNDO_ID WHERE s.BOOKMARK_NAME = :bookmark;

Audit activity by user and instance:

• SELECT CREATED_BY, SR_INSTANCE_ID, COUNT(*) FROM MSC.MSC_UNDO_SUMMARY WHERE CREATION_DATE >= :from_date GROUP BY CREATED_BY, SR_INSTANCE_ID;

Related Objects

The FK structure identifies the primary dependency:

• MSC_UNDO_DETAILS — child table; joins on MSC_UNDO_DETAILS.UNDO_ID = MSC_UNDO_SUMMARY.UNDO_ID, holding the individual change rows summarized here.
• MSC_PLANS — supplies the plan definition referenced by PLAN_ID.
• MSC_PLAN_SCHEDULES — related plan-run metadata associated with the same plan context.
• Planning output tables referenced by TABLE_CHANGED (for example MSC_SUPPLIES and MSC_DEMANDS) — the tables affected by the recorded undos.
• Standard audit columns reference FND_USER via the CREATED_BY / LAST_UPDATED_BY conventions.

Because MSC_UNDO_DETAILS is the sole documented foreign-key child, the summary table should always be queried together with its details table to obtain the full picture of any planning undo operation.