Search Results msd_dp_scenario_entries




Overview
Explore in AI Chat

Overview

MSD_DP_SCENARIO_ENTRIES is a fact table within the MSD (Demand Planning) product family of Oracle E-Business Suite, present and valid in both 12.1.1 and 12.2.2 environments. The table stores granular scenario entry detail — the individual demand-planning entries that users create or modify inside a named planning scenario. Each row represents one scenario entry, carrying both the entered value (quantity and amount) and its baseline counterpart, together with the full dimensional context in which the entry was made.

The documented physical schema, as captured in the ETRM 12.2.2 metadata, defines 68 columns owned by the MSD schema. The foreign-key structure shows the table is heavily oriented toward dimensional level references: it holds foreign keys into MSD_LEVEL_VALUES on seven separate level columns. Reflecting that structure, the heuristic Data Vault classification mined from the metadata is link — a modeling suggestion that this table behaves primarily as a relationship/association table connecting level-value hierarchies to the scenario entry event, rather than as a pure hub of business keys or a descriptive satellite.

Key Information Stored

The table is anchored by a composite unique index, MSD_DP_SCN_ENTRIES_U1, defined over (DEMAND_PLAN_ID, SCENARIO_ID, ENTRY_ID, REVISION). This constitutes the documented business-key candidate; no single surrogate primary-key column is separately recorded in the metadata. The most significant columns fall into three groups.

Common Use Cases and Queries

Typical usage centers on scenario comparison, adjustment auditing, and forecast accuracy reporting. A frequent pattern retrieves all entries for one scenario and plan, ordered by revision:

  • SELECT scenario_id, entry_id, revision, product_lvl_val, quantity, baseline_quantity FROM msd.msd_dp_scenario_entries WHERE demand_plan_id = :plan AND scenario_id = :scenario ORDER BY entry_id, revision;
  • Adjustment audit: filter on ADJUSTMENT_REASON IS NOT NULL to enumerate entries where planners overrode the baseline, comparing TOTAL_QUANTITY against BASELINE_TOTAL_QTY.
  • Accuracy reporting: aggregate FORECAST_ERROR by PRODUCT_LVL_VAL or by time bucket derived from TIME_LVL_VAL_FROM / TIME_LVL_VAL_TO.
  • Hierarchy joins: join the *_LVL_PK columns to MSD_LEVEL_VALUES to resolve coded level values into descriptive hierarchy names for BI output.

Related Objects

The dominant dependency is MSD_LEVEL_VALUES, referenced seven times through PRODUCT_LVL_PK, GEOGRAPHY_LVL_PK, ORGANIZATION_LVL_PK, SALESCHANNEL_LVL_PK, SALES_REP_LVL_PK, USER_DEFINED1_LVL_PK and USER_DEFINED2_LVL_PK (with parallel CUSTOMER_LVL_PK, DEMAND_CLASS_LVL_PK and SR_*_LVL_PK columns following the same pattern). These joins resolve the dimensional context of every entry. Scenario metadata is held in the parent scenario and demand-plan tables that supply DEMAND_PLAN_ID, SCENARIO_ID and SCENARIO_NAME, though those relationships are not enumerated as declared foreign keys in the supplied metadata. Downstream, Demand Planning reports, the MSD scenario comparison engine and forecast-accuracy extracts consume this table directly. Because the declared FK set points exclusively to MSD_LEVEL_VALUES, integrators should treat level resolution as the primary join path and verify scenario/plan parent relationships against the MSD data model before relying on them.