Search Results supply_allocated_quantity




Overview

APPS.MRPFV_PLAN_PEGS is a business intelligence system view in the Oracle E-Business Suite Applications schema. It exposes the full pegging information associated with an Oracle Advanced Supply Chain Planning (ASCP) or MRP plan, where each row represents the allocation of a single supply order to a specific end demand. In other words, the view answers the question "which supply is satisfying which demand, and by how much" for every item, organization, and plan combination loaded into the planning tables.

Because it is defined as a view rather than a table, MRPFV_PLAN_PEGS presents a denormalized, reporting-friendly projection of the underlying pegging records. It resolves organization and item identifiers into readable codes and names, applies manufacturing lookup meanings to supply and demand types, and joins project context where applicable. This makes it directly consumable by BI Publisher reports, Discoverer worksheets, OBIEE repositories, custom concurrent programs, and SQL*Plus extracts without requiring the developer to reconstruct the join logic manually. The object carries an FND Design Data reference of MRP.MRPFV_PLAN_PEGS and is documented as VALID in the ETRM metadata for release 12.1.1 and 12.2.2.

Underlying Base Objects

The view is defined over several base objects in the APPS schema. The core pegging data is sourced from MRP_FULL_PEGGING, which stores the supply-to-demand allocation records generated by the planning engine. MTL_SYSTEM_ITEMS and MRP_SYSTEM_ITEMS supply item attributes, while HR_ALL_ORGANIZATION_UNITS and MTL_PARAMETERS provide organization code and name context. MFG_LOOKUPS translates the numeric supply and demand type codes into descriptive meanings. The MRP_GET_PROJECT package is referenced to resolve project and task numbering, which is why PROJECT_NUMBER and TASK_NUMBER are exposed with the unusually wide VARCHAR2(4000) length.

Notably, the view is not referenced by any other database object, confirming that it is a terminal reporting construct intended for direct consumer access rather than as a building block for further views or packages.

Key Columns

Each row includes identifiers such as ORGANIZATION_CODE, ORGANIZATION_NAME, PLAN_NAME, and the item key flexfield column _KF:ITEM_NUMBER. Quantities are captured by DEMAND_QUANTITY, SUPPLY_QUANTITY, and SUPPLY_ALLOCATED_QUANTITY — the last of which is the specific column users search for when reconciling how much of a given supply order has been applied against a specific demand.

  • SUPPLY_ALLOCATED_QUANTITY: the portion of the supply order applied to the matched demand row; the central measure for pegging analysis.
  • DEMAND_QUANTITY / SUPPLY_QUANTITY: total quantities on the demand and supply sides of the peg.
  • DEMAND_DATE / SUPPLY_DATE: the scheduled dates for the demand requirement and the supply receipt.
  • SUPPLY_TYPE / DEMAND_TYPE_OF_END_DEMAND: lookup-driven descriptions of the order classes involved.
  • PEGGING_ID, PREV_PEGGING_ID, END_PEGGING_ID: keys that allow traversal of the pegging chain from an intermediate supply back to the originating end demand.
  • END_ITEM_USAGE: the quantity of the end item consumed per unit, supporting cumulative usage calculations.
  • PROJECT_NUMBER / TASK_NUMBER / PROJECT_ID / TASK_ID: project manufacturing context for the peg.

Common Use Cases and Queries

Typical uses include supply-demand reconciliation for a plan, identifying which work orders or purchase orders are pegged to a late sales order, and analyzing project-based pegging. A representative query filters by plan and item:

  • SELECT organization_code, plan_name, _KF:ITEM_NUMBER, supply_type, demand_type_of_end_demand, supply_allocated_quantity, demand_date, supply_date FROM apps.mrpfv_plan_pegs WHERE plan_name = :plan AND organization_code = :org ORDER BY _KF:ITEM_NUMBER, supply_date;
  • Sum allocated quantity per supply order: SELECT plan_supply_id, SUM(supply_allocated_quantity) FROM apps.mrpfv_plan_pegs GROUP BY plan_supply_id;
  • Trace a peg chain using PEGGING_ID, PREV_PEGGING_ID, and END_PEGGING_ID to walk from an intermediate supply to the end demand.

Because the view resolves codes and names, it is well suited to end-user reporting, but it should be queried with plan and organization predicates to limit volume, as the underlying pegging table can be very large.