Skip to main content

bpas_revamp

Beas Feature 02 · Concepts

MRP Wizard and MRP2 5 Core Concepts

The thinking behind every Buy and Make proposal.

The Five Concepts

From net requirements to decisions you own

Two stages. How the requirement is calculated: net requirements, origins and dates. Checking and acting on it: resource load and the planner's decision.

  1. Concept 01 · Use stock and planned receipts before buying or making more

    Net Requirements, Not Gross

    The shop-floor problem it solves

    The plant buys or makes again what is already on the shelf or already on order, and cash sits in duplicate stock.

    The concept explained

    MRP always breaks down assembly requirements, for example from a customer order, through the bill of materials. When a component is a stock-related sub-assembly, Beas first checks whether stock or planned inflow can cover it, and reserves that cover temporarily for the requirement. Only the part that stays uncovered is broken down further. This is the requirement coverage calculation. With Coverage calculation priority set to By Documents, it follows this priority: minimum inventory first, then the production outflow of work orders and planned orders, then customer orders, advance invoices and forecasts set “like customer order”, then transfer requests, then other forecasts. Breakdown replenishment sets which inflows count. With every option on, the breakdown is net; with none, it is gross, and the stock of the sub-assembly no longer reduces the material requirement.

    Everyday analogy

    Before writing the weekly grocery list, you check the kitchen shelf and what is already ordered from the kirana store. Only what is still missing goes on the list, and nobody comes home with a second bag of rice.

    Where it lives in Beas

    MRP > MRP Wizard > Open > Detail tab > Breakdown replenishment holds Consider goods receipt from production, Include warehouse stock, Consider goods receipt from PO and Consider multiple orders. Coverage calculation priority (By Documents or By Date) sits under Pegging and replenishment > Computation type. After a run, Order recommendation > Origin shows the temporary reservations.

    Net and gross breakdownIllustrative: an order needs 100 of sub-assembly B, 50 B are in stock and each B needs 5 of material C. Net breakdown, with all Breakdown replenishment options on, uses the 50 in stock and makes 50, so C is required 250 times. Gross breakdown, with no options on, breaks down all 100, so C is required 500 times.Net breakdownAll options onRequirement for B: 10050 in stock50 to make× 5 C eachRequirement for C250Gross breakdownNo options onRequirement for B: 100100 broken down× 5 C eachRequirement for C500Stock of B is used first50 B in stock not used
    Illustrative figures: net breakdown uses the stock of the sub-assembly first, so less material is required.
  2. Concept 02 · Every proposal traces back to the order or forecast behind it

    Every Requirement Has an Origin

    The shop-floor problem it solves

    A purchase is proposed and nobody can say which order or forecast caused it, so the list is second-guessed line by line.

    The concept explained

    In Beas, the originator of a requirement is its pegging, such as a customer order, a work order, a forecast or minimum inventory. When MRP breaks an assembly down, the requirements it creates below can be traced back to the pegging that caused them. After the calculation, the Origin of Requirement structure shows which pegging caused which requirement, from which peggings a requirement arose and which inflow covers it, including temporary reservations. How much of that link survives depends on Sum peggings. With Detail, every pegging is shown separately, which suits order-related purchases and high-value goods. Summarising by day, week or month calculates faster with large data volumes, but the reference to the pegging is lost.

    Everyday analogy

    A household list where every line says who it is for: notebooks for the school project, extra rice for Sunday's guests. Write only “monthly shopping” and nobody can later say why there are twelve notebooks in the cupboard.

    Where it lives in Beas

    In the Order recommendation, right-click in the inflow and outflow tab and choose Origin to open the Origin of Requirement structure. Sum peggings sits in Detail tab > Pegging and replenishment > Computation type. Items outside the Scheduling tab filters are not saved, and their links cannot be shown.

    Every requirement has an originThree peggings, a customer order, a work order and a forecast, cause a requirement for sub-assembly B, which causes a requirement for material M and an order recommendation to buy. Origin traces each requirement back to its pegging. With Sum peggings set to Detail every pegging is shown; summarised by day, week or month the pegging reference is lost.Peggings: the originatorsCustomer orderWork orderForecastRequirement: sub-assembly BRequirement: material MOrder recommendation: BuyOrigintraces eachrequirementbackSum peggingsDetailevery pegging shownDay, week, monthpegging reference lost
    Every requirement traces back to its pegging, unless peggings are summarised.
  3. Concept 03 · Work back from the requirement date, not forward from today

    Order on Time, Not Early

    The shop-floor problem it solves

    Material arrives weeks too early and ties up cash, or a day too late and the line stops.

    The concept explained

    Every requirement carries a date: the delivery date of a customer order, the planned date of a forecast, or, for a work order component linked to a routing position, the start of that operation (with Consider link to operations on). MRP works back from that date. For customer orders the average delivery time is subtracted first; then the lead time and buffer days, and for purchased parts the goods receipt idle time as well. That is why the order proposal date is not the requirement date. For assemblies, Calculate lead time for assembly runs a backward scheduling simulation over the routing to find the latest possible start; existing capacities and time reservations are not considered. For sub-assemblies it applies only to order-related ones; storage-related sub-assemblies keep the fixed lead time from the item master. If the result lies in the past, the proposal moves to the next working day.

    Everyday analogy

    Booking a gas cylinder refill. Delivery takes a few days, so you book when a few days of gas are left, not the week the last cylinder arrived and not on the evening it runs out.

    Where it lives in Beas

    Lead time sits in Item master > Master Data tab > Planning data, in work days; a lead time of 0 is flagged as an error by the data check. Calculate lead time for assembly sits in Detail tab > Pegging and replenishment > Computation type. Average lead time, Lead time assurance and Goods receipt PO idle time in workdays (Purchased items) sit in Administration > System Initialization > Configuration Wizard > Materials management > MRP Wizard > Calculation.

    Order proposal date worked back from the requirement dateTop: starting from the requirement date, the average delivery time (for customer orders), the lead time and buffer days are subtracted to reach the order proposal date. Bottom: if the calculated date is in the past, the proposal moves to the next working day after today.Worked back from the requirement dateBuffer daysLead timeAvg. delivery timecustomer ordersRequirement dateOrder proposal dateIf the result is in the pastTodayCalculated: in the pastNext working day
    For customer orders the average delivery time comes off first, then lead time and buffer days; a date in the past moves to the next working day.
  4. Concept 04 · Check resource load in the same scenario as material

    Material and Capacity in One Run

    The shop-floor problem it solves

    Materials are planned and bought, but the machines cannot make the order in time, so the shortage moves from the store to the shop floor.

    The concept explained

    A material plan says what to buy and make, not whether the plant has the hours to make it. With Enable resource scheduling switched on, Beas calculates the resources a scenario needs on top of its material requirements. This is MRP2. Requirement of resources MRP2 lists each resource with the hours from Forecasts, Sales order and Production against its Capacity, viewed by day, week or month. When the workload exceeds 90% of a resource's dispatching index, it is marked Overloaded, and Peggings Resources lists the peggings behind the load in the selected period. MRP2 is based on the lead time calculation, so Calculate lead time for assembly must be on and Forecast > Gross calculation off. The calculation takes longer.

    Everyday analogy

    Cooking for a family function. All the groceries are bought, but the kitchen has one stove with four burners. Unless someone also checks the burner hours, the sweets for sixty guests are not ready when the first guests arrive.

    Where it lives in Beas

    MRP > MRP Wizard > select a scenario > Resources opens Requirement of resources MRP2. Enable resource scheduling sits in Detail tab > Resources, and the Calculate resources column of the scenario list shows where it is active. Clicking a utilization bar opens the Origin of Requirement structure.

    Material and capacity in one runLeft: the material requirements of a scenario, what to buy and what to make. Right: Requirement of resources MRP2 for one resource by week, with illustrative workload bars and a line at 90 percent of the dispatching index. Week 3 exceeds it and is marked Overloaded.MaterialrequirementsBuyMaterial MMakeSub-assembly BPlannedwhat to buy and make+Requirement of resources MRP2One resource by week · illustrativeWorkload90% of dispatching indexW1W2OverloadedW3W4W5
    Illustrative figures: material and resource load from the same scenario; a week above 90% of the dispatching index is Overloaded.
  5. Concept 05 · MRP proposes; the planner decides what becomes a request

    Recommend, Then Decide

    The shop-floor problem it solves

    Either every proposal is turned into an order without a second look, or the list is ignored and buying goes back to spreadsheets.

    The concept explained

    The result of an MRP run is a recommendation, not a document. The Order recommendation shows, per item and period, the quantity to Buy, Make or Transfer, and the planner decides what happens next. Single mode is the default view. Massive mode works on all lines at once: Create request turns each line into a purchase request, a production request or an inventory transfer request, and Pre-Assign works out, for storage-related assemblies, what is needed for the next lead time plus buffer days. Production requests become work orders, and purchase requests become purchase orders. With Consider purchase and production requests on, open requests count as inflow in the next calculation; the option appears only when Purchase order and Request are activated under Purchase in the Detail tab.

    Everyday analogy

    A family member drafts the week's shopping list; the person running the kitchen strikes off what is not needed and only then places the order. Next week's list starts from what is now in the kitchen.

    Where it lives in Beas

    MRP > MRP Wizard > select a scenario > Order recommendation; the mode button switches to Massive mode. MRP > Production Request creates work orders as Individual orders, a Collective Order or Merge; Merge drops the link to the sales order, so use it for warehouse-related production only. Automatic calculation on the Scheduling tab runs the scenario through the Beas service planned activity “Calculate MRP”. Detail tab > Authorization sets Setup, View and Calculation rights per scenario.

    BPAS Exclusive Enhancement · misBoostPlanned against made, every morning: Production & Planning boosters built from your Beas and SAP Business One data, sent on autopilot.
    Recommend, then decideA loop of five steps: calculate the scenario by hand or automatically; the order recommendation proposes Buy, Make or Transfer; the planner decides in Single or Massive mode; purchase, production or inventory transfer requests are created; production requests become work orders and purchase requests purchase orders. Open requests count as inflow in the next calculation.Recommend,then decideevery runCalculateBy hand or automatic1Order recommendationBuy · Make · Transfer2Planner decidesSingle or Massive mode3RequestsPurchase · production · transfer4Work ordersand purchase orders5Open requests countas inflow next run
    Calculate, recommend, decide, request, produce or buy, and calculate again.
Quick Self-Check

Five questions for your next planning meeting

One question per concept. Ask them of your planner, buyer and plant head together, and compare the answers.

Two or more "no" answers usually means the plan is costing you overtime, freight and missed dates.

  1. Does MRP subtract our stock and open orders before it proposes anything?Concept 01 · Net requirements, not gross
  2. Can a buyer show which customer order or forecast caused any purchase proposal?Concept 02 · Every requirement has an origin
  3. Does material arrive close to the day it is needed, not weeks early or a day late?Concept 03 · Order on time, not early
  4. Do we check resource load against capacity before we commit the material plan?Concept 04 · Material and capacity in one run
  5. Does a planner review each order recommendation before it becomes a purchase or work order?Concept 05 · Recommend, then decide
Go Deeper

More on MRP Wizard and MRP2

Test these five ideas on your own plant

In a BPAS gap review we look at your SAP B1 data, your item planning data and your MRP scenarios, and show you which of the five concepts is costing you most today.