Search Results mrp_planned_order_demand




Overview
Explore in AI Chat

Overview

APPS.MRPBV_PLAN_PEGS is a read-only reporting view in Oracle E-Business Suite that exposes the pegging relationships maintained by the Material Requirements Planning (MRP) engine. Pegging is the mechanism by which MRP links each supply to the discrete demand that consumes it, producing the top-down and bottom-up traceability that planners rely on when investigating why a planned order, suggested replenishment, or on-hand quantity exists. The view is defined over the MRP_FULL_PEGGING synonym and joins the MFG_LOOKUPS view twice to resolve supply types and end-origination types into user-facing meanings. It is intended for reporting and integration rather than transaction processing; the DDL carries a WITH READ ONLY clause and a security predicate of the form _SEC:PEG.ORGANIZATION_ID IS NOT NULL, which enforces organization-level access control under Multi-Org security (MOAC). The name suffix "BV" identifies it as a business view within the MRP family, and it is most frequently queried to answer the recurring question of where a given planned order's demand originates — the search pattern "mrp_planned_order_demand" maps directly to the DECODE logic that classifies end-origination records into the MRP_PLANNED_ORDER_DEMAND lookup type.

Underlying Base Objects

The view is constructed from two documented referenced objects: MFG_LOOKUPS (itself a view over the FND lookup infrastructure, providing lookup codes and their MEANING values) and MRP_FULL_PEGGING, presented in the metadata as a SYNONYM. Both lookup joins are outer joins, signalled by the (+) operator, so a pegging row is never suppressed merely because a corresponding lookup definition is missing. The first join resolves PEG.SUPPLY_TYPE against LOOKUP_TYPE = 'MRP_ORDER_TYPE', and the second resolves the end-origination code against a lookup type chosen dynamically by a DECODE expression: values 1, 3, and 25 are translated to the lookup type MRP_PLANNED_ORDER_DEMAND, while all other values fall to MRP_DEMAND_ORIGINATION. That DECODE is the semantic heart of the view, distinguishing pegs whose ultimate origin is a planned order from those originating in genuine external or internal demand. Because a synonym is involved, the physical pegging table may reside in the MRP schema and be shared across application modules.

Key Columns

  • DEMAND_QUANTITY / SUPPLY_QUANTITY / ALLOCATED_QUANTITY — the quantities on each side of the peg and the portion of supply allocated to the demand. Negative or partial allocations are normal and indicate surplus supply.
  • DEMAND_DATE / SUPPLY_DATE — the requirement date of the demand and the availability date of the supply; the gap between them drives expedite and reschedule messages.
  • MEANING (LKUP) / MEANING (LKUP2) — decoded supply order type (from MRP_ORDER_TYPE) and decoded end-origination type (from MRP_PLANNED_ORDER_DEMAND or MRP_DEMAND_ORIGINATION).
  • PEGGING_ID / PREV_PEGGING_ID / END_PEGGING_ID — the identifiers that chain individual peg records into a supply chain path; END_PEGGING_ID marks the terminal record, enabling recursive traversal.
  • ORGANIZATION_ID — the inventory organization; the MOAC predicate is applied here.
  • INVENTORY_ITEM_ID / COMPILE_DESIGNATOR — the pegged item and the plan (compile designator) under which the pegging was generated.
  • TRANSACTION_ID / DEMAND_ID — identifiers of the originating supply transaction and the demand record.
  • PROJECT_ID / TASK_ID — project and task references for project-aware pegging.
  • END_ITEM_USAGE — indicates whether the pegged item is an end item, useful for identifying independent demand.
  • Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY.

Common Use Cases and Queries

Typical uses include planned-order pegging reports, supply/demand traceability for expedite review, and integration extracts that feed downstream planning or analytics systems. A representative query retrieving planned-order demand originations follows:

  • SELECT PEGGING_ID, INVENTORY_ITEM_ID, ORGANIZATION_ID, DEMAND_QUANTITY, SUPPLY_QUANTITY, DEMAND_DATE, SUPPLY_DATE FROM APPS.MRPBV_PLAN_PEGS WHERE ORGANIZATION_ID = :org_id AND COMPILE_DESIGNATOR = :plan;
  • SELECT * FROM APPS.MRPBV_PLAN_PEGS WHERE MEANING = 'Planned Order' AND END_ITEM_USAGE = 'Y';
  • SELECT DEMAND_ID, SUM(DEMAND_QUANTITY) FROM APPS.MRPBV_PLAN_PEGS WHERE INVENTORY_ITEM_ID = :item AND ORGANIZATION_ID = :org_id GROUP BY DEMAND_ID;

When automating pegging chains, iterate from END_PEGGING_ID back through PREV_PEGGING_ID to reconstruct the full supply path. Note the read-only nature of the view when designing interfaces.