Search Results msc_st_demands




Overview
Explore in AI Chat

Overview

MSC_ST_DEMANDS is a staging table owned by the MSC schema within Oracle Advanced Supply Chain Planning (ASCP). Its documented purpose is to receive unvalidated demand records collected from source applications, hold them while the collection program performs validation and transformation, and then promote the accepted rows into the permanent planning table MSC_DEMANDS. In Oracle EBS 12.1.1 and 12.2.2 this staging mechanism is the standard interface between transactional systems — Order Management, Work in Process, Purchasing, Service, and external or legacy sources — and the Advanced Planning engine. Because the planner consumes data from MSC_DEMANDS, not directly from the source modules, MSC_ST_DEMANDS is best understood as a transient landing zone whose lifecycle is tied to a single collection run.

The table is documented with 144 columns and no declared primary key or unique index in the ETRM extract. The Data Vault classification mined from its foreign-key structure is standalone, meaning the heuristic model treats it as neither a hub, link, nor satellite but as an independent staging artifact. From a modeling perspective this is consistent with a table that is truncated and reloaded per collection cycle rather than accumulated as historical fact.

Key Information Stored

The row-level identity of a staged record is carried by DEMAND_ID, the surrogate identifier that ultimately maps to the planning demand in MSC_DEMANDS. Business-key candidates are composite: the combination of INVENTORY_ITEM_ID, ORGANIZATION_ID, DEMAND_TYPE, and the source reference columns (SALES_ORDER_NUMBER, ORDER_NUMBER, WIP_ENTITY_ID) is what the collection program uses to reconcile a staged row against its source transaction.

Common Use Cases and Queries

The most frequent operational need is diagnostics: identifying rows that failed validation before promotion to MSC_DEMANDS.

  • Error inspection: SELECT DEMAND_ID, INVENTORY_ITEM_ID, ORGANIZATION_ID, ERROR_TEXT FROM MSC_ST_DEMANDS WHERE ERROR_TEXT IS NOT NULL;
  • Run-scoped reconciliation: filter by REQUEST_ID or SR_INSTANCE_ID to isolate the rows produced by one collection run and compare counts against the target table.
  • Source traceability: join to MTL_SYSTEM_ITEMS_B, OE_ORDER_HEADERS_ALL, or MTL_PARAMETERS on INVENTORY_ITEM_ID, SALES_ORDER_NUMBER, and ORGANIZATION_ID to reconcile staged demand to its originating transaction.
  • Duplicate detection: group by item, organization, and source reference to detect records staged twice within a snapshot.
  • Stuck-row analysis: rows persisting across multiple REFRESH_ID values indicate a collection failure and warrant investigation.

Because the table is transient, queries should always constrain on the current collection request or refresh identifier to avoid scanning obsolete data.

Related Objects

The FK metadata documents six outbound references that anchor staged rows to their source transactions.

Collection and planning programs in the MSC schema, together with the concurrent manager request recorded in REQUEST_ID, complete the dependency chain that moves data from transactional sources through this staging table into the ASCP planning engine.