Results for “msc_demand_pegging_v”

22 results




Overview
Explore in AI Chat

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

Overview

MSC_DEMAND_PEGGING_V is an APPS-owned database view within the Oracle Advanced Supply Chain Planning (MSC) module. It exposes demand pegging relationships generated by the MSC planning engine, allowing planners and reporting tools to trace how independent and dependent demand is satisfied by supplies across the supply chain plan. In Oracle EBS 12.1.1 and 12.2.2 the object remains a read-only view over the planning staging tables MSC_DEMANDS and MSC_FULL_PEGGING; no business logic is duplicated in PL/SQL, which makes the view a stable integration point for custom reports, BI Publisher datasets, OBIEE/OTBI extracts, and third-party planning dashboards.

The view is best understood as a flattened, self-joined projection of the pegging hierarchy. It joins the pegging table to itself (aliases PEG1 and PEG2) so that each row represents an allocated quantity flowing from a supply-side pegging record (PEG1) to a demand-side pegging record (PEG2), then decorates that relationship with attributes from the two MSC_DEMANDS rows (D1 for the parent demand class, D2 for the demand being pegged). The net effect is a demand-to-demand allocation map keyed by plan, item, organization, and source instance.

Underlying Base Objects

The documented base objects referenced by the view are the synonyms MSC_DEMANDS and MSC_FULL_PEGGING, both resolving to tables in the APPS schema:

The join predicates require matching PLAN_ID and SR_INSTANCE_ID across both pegging aliases and both demand aliases, and they link PEG2.END_PEGGING_ID to PEG1.PEGGING_ID to walk the pegging chain. A significant filter is applied to the second demand alias: D2.ORIGINATION_TYPE NOT IN (5,7,8,9,11,15,22,28,29,31). This suppresses demand records originating from supply-side or internal planning constructs, so the view returns only true end-demand pegging.

Key Columns

  • PLAN_ID — identifies the MSC plan; every query should filter on it.
  • INVENTORY_ITEM_ID and ORGANIZATION_ID — the planned item and its organization context.
  • SR_INSTANCE_ID — source instance, used to distinguish data from multiple source systems.
  • DEMAND_CLASS — derived via NVL(D1.DEMAND_CLASS,'-1'); the parent demand's class, defaulting to -1 when null.
  • DEMAND_DATE — taken from D2.USING_ASSEMBLY_DEMAND_DATE, the date the demand is required.
  • ALLOCATED_QUANTITY — the quantity of the supply pegged to the demand.
  • DEMAND_ID — the pegged demand's identifier, joinable back to MSC_DEMANDS.
  • ORIGINATION_TYPE — the classified source of the pegged demand (e.g., sales order, forecast, internal order). Because the view filters specific codes, only certain origin types survive.
  • ORDER_NUMBER and SALES_ORDER_LINE_ID — the originating order reference and, for sales order demand, the line identifier.

Common Use Cases and Queries

Typical uses include pegging analysis for a given item/plan, tracing supply to top-level demand, and building reports that break allocated quantity down by DEMAND_CLASS or ORIGINATION_TYPE.

SELECT demand_id, order_number, origination_type,
       demand_date, allocated_quantity, demand_class
  FROM apps.msc_demand_pegging_v
 WHERE plan_id = :p_plan_id
   AND inventory_item_id = :p_item_id
   AND organization_id = :p_org_id
 ORDER BY demand_date;

Aggregating allocated quantity by ORIGINATION_TYPE is a common way to reconcile how much planned supply is committed against each demand source, while joining DEMAND_ID back to MSC_DEMANDS enriches the output with customer and order detail. Because the view filters the disallowed origination types internally, no additional exclusion logic is required in downstream queries.