Search Results original_demand_id




Overview

MSC.MSC_ATP_DETAIL_PEG_TEMP is a global temporary table in the MSC (Advanced Supply Chain Planning / VCP) schema. It is registered in Oracle E-Business Suite FND Design Data as MSC.MSC_ATP_DETAIL_PEG_TEMP and holds a VALID status in the 12.1.1 and 12.2.2 releases. The table is defined as a global temporary table with a data duration of SYS$TRANSACTION, meaning that rows inserted by a session are visible only to that session and are deleted when the transaction commits. This design is characteristic of an intermediate planning workspace, where the ATP (Available-to-Promise) engine stages pegging and demand/supply detail during a planning or promising run before results are consumed or merged into permanent planning tables.

The table consists of 41 documented columns and one non-unique index, MSC_ATP_DETAIL_PEG_TEMP_N1, on the combination of PLAN_ID, SR_INSTANCE_ID, REFERENCE_ITEM_ID, and SALES_ORDER_LINE_ID. That index reflects the primary access pattern: retrieving detail rows for a given plan, source instance, and item/sales order combination. From a Data Vault modeling perspective, the metadata classifies this object as standalone; because it has only one documented foreign key (PEGGING_ID to MRP_FULL_PEGGING), it does not behave as a conventional hub, link, or satellite, but rather as a transient staging structure for pegging detail.

Key Information Stored

The columns capture the demand-to-supply pegging relationship plus ATP-relevant quantities and dates. The most significant columns include:

No surrogate primary key is documented; the only documented unique constraint is absent, so business-key uniqueness is not enforced on this temporary structure. Identification is instead driven by the composite index columns.

Common Use Cases and Queries

The table is typically consumed within ATP or planning concurrent programs. Typical use cases include debugging an ATP pegging result, tracing which supply satisfies a given demand, and analyzing forecast consumption and overconsumption. Because it is a session-scoped temporary table, queries must run in the same session that populated it.

Sample pattern to trace demand lineage:

  • SELECT DEMAND_ID, ORIGINAL_DEMAND_ID, DEMAND_QUANTITY, SUPPLY_ID, ALLOCATED_QUANTITY FROM MSC_ATP_DETAIL_PEG_TEMP WHERE PLAN_ID = :plan_id AND ORIGINAL_DEMAND_ID = :demand_id;
  • SELECT REFERENCE_ITEM_ID, SALES_ORDER_LINE_ID, DEMAND_DATE, SUPPLY_DATE FROM MSC_ATP_DETAIL_PEG_TEMP WHERE PLAN_ID = :plan_id AND SR_INSTANCE_ID = :sr_instance_id;

Reporting use cases focus on pegging reports, ATP availability checks, and reconciliation between forecast and consumed quantities.

Related Objects

The documented foreign key links PEGGING_ID to MRP_FULL_PEGGING, which supplies the persistent pegging chain. Other significant related objects include MSC.MRP_FULL_PEGGING for full pegging detail, the permanent ATP detail tables that receive promoted results, the sales order tables referenced through SALES_ORDER_LINE_ID and ORDER_NUMBER, the planning plan and organization tables referenced through PLAN_ID and ORGANIZATION_ID, and the source instance reference for SR_INSTANCE_ID. Access is generally through the MSC planning and ATP concurrent programs rather than direct SQL against this temporary store.