Results for “msd_dp_scenario_revisions_u1”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

MSD.MSD_DP_SCENARIO_REVISIONS is a table in the Oracle E-Business Suite Demand Planning (MSD) schema. It functions as the header table for scenario entries within the Demand Planning workbench, storing one row per revision of a demand plan scenario. Each row identifies a demand plan, a scenario, and a revision identifier, together with a user-defined revision name and supporting metadata. This structure allows multiple named revisions of the same plan-and-scenario combination to be preserved, compared, and referenced by downstream planning processes.

The object resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10 and carries the status VALID. It is registered in FND Design Data as MSD.MSD_DP_SCENARIO_REVISIONS. Its primary key is documented as MSD_DP_SCENARIO_REVISIONS_UK1 (SCENARIO_ID, DEMAND_PLAN_ID, REVISION). From a Data Vault modeling perspective, the heuristic classification for this object is standalone, meaning it does not itself participate in an explicit foreign-key dependency graph. In practice, the business-key triad of SCENARIO_ID, DEMAND_PLAN_ID, and REVISION behaves as the natural key, while the standard "who" columns supply audit history.

Key Information Stored

The most significant columns are:

• DEMAND_PLAN_ID (NUMBER) — identifies the demand plan to which the revision belongs; part of the unique business key.
• SCENARIO_ID (NUMBER) — identifies the scenario within the demand plan; part of the unique business key.
• REVISION (VARCHAR2(40)) — the revision identifier; part of the unique business key.
• REVISION_NAME (VARCHAR2(100)) — user-defined descriptive label for the revision.
• ERROR_TYPE (VARCHAR2(30)) — error classification associated with the revision, typically populated during upload processing.
• PLAN_START_DATE (DATE) — plan start date for the previous liability that is uploaded.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard Oracle "who" columns capturing audit and concurrency information.

The unique index MSD_DP_SCENARIO_REVISIONS_U1 (SCENARIO_ID, DEMAND_PLAN_ID, REVISION), stored in APPS_TS_TX_IDX as a NORMAL UNIQUE index, enforces the business key. There is no separately documented surrogate key column; the business key doubles as the primary identifier. DEMAND_PLAN_ID and SCENARIO_ID tie each revision back to its owning plan and scenario, while REVISION distinguishes multiple saved versions.

Common Use Cases and Queries

Typical uses include enumerating all revisions for a plan/scenario combination, producing revision comparison reports, auditing which user created a revision and when, and identifying revisions that produced upload errors. A basic query follows the documented query text:

• SELECT DEMAND_PLAN_ID, SCENARIO_ID, REVISION, REVISION_NAME, PLAN_START_DATE, ERROR_TYPE FROM MSD.MSD_DP_SCENARIO_REVISIONS WHERE SCENARIO_ID = :scenario_id AND DEMAND_PLAN_ID = :plan_id ORDER BY REVISION;
• To isolate problem revisions: filter on WHERE ERROR_TYPE IS NOT NULL.
• To review recent activity: order by LAST_UPDATE_DATE DESC and filter LAST_UPDATED_BY = :user_id.

The table also supports joins to the scenario entries materialized view to reconcile header-level revision metadata with detailed scenario entry rows.

Related Objects

• APPS.MSD_DEM_SCN_ENTRIES_MV — the scenario entries materialized view; it references MSD_DP_SCENARIO_REVISIONS and joins on SCENARIO_ID, DEMAND_PLAN_ID, and REVISION to resolve entry-level detail against revision headers.
• MSD_DP_SCENARIO_REVISIONS — the table itself is listed among the objects that reference it, reflecting internal/self-referencing dependency metadata rather than an external FK.

No other database objects are documented as referencing this table, consistent with its standalone classification. Join predicates should therefore rely on the business-key columns (SCENARIO_ID, DEMAND_PLAN_ID, REVISION) rather than an enforced foreign key.