Search Results msc_undo_details_u1

Overview

MSC.MSC_UNDO_DETAILS is a transactional detail table in the Oracle E-Business Suite Advanced Supply Chain Planning (ASCP) schema, MSC. The table records the granular, column-level changes made to plan output when a planner executes an undo operation. Where MSC_UNDO_SUMMARY captures the header-level context of an undo event, MSC_UNDO_DETAILS stores the individual attribute that changed, its prior value, and its new value, enabling planners to audit and reverse planning decisions such as manually edited supply quantities, dates, or sourcing assignments.

The object resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, and it is documented as VALID in the ETRM 12.2.2 repository. Its documented foreign key, UNDO_ID referencing MSC_UNDO_SUMMARY, establishes a master-detail relationship that makes the table a natural candidate for satellite-leaning modeling within a Data Vault heuristic: the immutable, descriptive change attributes attach to a parent undo event and change independently of the plan itself. The table is also referenced by the MSC_UNDO_DETAILS# internal construct, which is typical of tables carrying a globally unique identifier or extension column.

Key Information Stored

The table contains fourteen documented columns. The principal ones are:

• UNDO_ID (NUMBER) — Undo Identifier; participates in the composite unique index and joins to MSC_UNDO_SUMMARY.UNDO_ID, forming the parent link.
• COLUMN_CHANGED (VARCHAR2 30) — The name of the attribute within the plan output that was modified; the second component of the unique index MSC_UNDO_DETAILS_U1.
• COLUMN_CHANGED_TEXT (VARCHAR2 240) — Descriptive text qualifying the type of column change.
• OLD_VALUE (VARCHAR2 240) — The value of the attribute prior to the undo operation.
• OLD_VALUE_ID (VARCHAR2 240) — An identifier for the old value, useful when the value resolves to a coded or keyed reference.
• NEW_VALUE (VARCHAR2 240) — The value of the attribute after the undo operation.
• NEW_VALUE_ID (VARCHAR2 240) — Identifier corresponding to the new value.
• COLUMN_TYPE (VARCHAR2 30) — The category or data type classification of the changed column.
• PLAN_ID (NUMBER) — Plan Identifier linking the change to a specific planning scenario.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who columns providing audit attribution and timestamps.

The surrogate primary key is conventionally UNDO_ID combined with COLUMN_CHANGED, formalized by the unique index MSC_UNDO_DETAILS_U1. There is no separate sequence-backed column documented as a numeric primary key, so the composite business key doubles as the uniqueness guarantee for a given undo event and changed column.

Common Use Cases and Queries

Typical usage centers on auditing manual planning edits and verifying that an undo restored the expected values. A planner may query all changes associated with a single undo event:

SELECT UNDO_ID, COLUMN_CHANGED, OLD_VALUE, NEW_VALUE, PLAN_ID
FROM MSC.MSC_UNDO_DETAILS
WHERE UNDO_ID = :undo_id
ORDER BY COLUMN_CHANGED;

Reporting use cases include reconstructing the before-and-after state of a supply plan element, identifying which columns planners most frequently overwrite via the COLUMN_CHANGED frequency distribution, and reconciling undo activity by plan using PLAN_ID. The full-column projection supplied in the metadata (SELECT UNDO_ID, COLUMN_CHANGED, COLUMN_CHANGED_TEXT, OLD_VALUE, OLD_VALUE_ID, NEW_VALUE, NEW_VALUE_ID, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, COLUMN_TYPE, PLAN_ID) serves as a convenient extraction pattern for downstream audit warehouses.

Related Objects

• MSC.MSC_UNDO_SUMMARY — Parent table referenced by MSC_UNDO_DETAILS.UNDO_ID; join on UNDO_ID to retrieve header-level undo context.
• MSC.MSC_UNDO_DETAILS# — Internal dependent object listed as referencing this table.
• MSC.MSC_PLANS — Implied reference via PLAN_ID, the plan identifier carried on each detail row.
• ASCP concurrent programs (Plan Undo, Plan Purge) — Populate and consume MSC_UNDO_DETAILS during undo processing.

Because the documented dependency list is limited, joins to MSC_PLANS on PLAN_ID and to MSC_UNDO_SUMMARY on UNDO_ID represent the most reliable paths for expanded reporting.