MRP Overview

Material Requirements Planning (MRP) is a mode of planning that plans requirements in order by the lowest level in which the item appears in a bill of material. That is, it plans all end items first, then all items at the next level, and so on, backward planning each requirement from the requirement's needed date to the item's lead time and batching together requirements needed at the same period of time.

Unlike APS, MRP does not consider routing times, resource capacity, or shifts. The responsibility rests with you, the planner, to make sure your shop floor has the available capacity to work the plan. MRP generates planned orders and exception messages to help you implement an accurate plan.

Information MRP Uses to Plan

Low-level Codes and Bills of Material

Each item has a low-level code that represents the lowest level at which the item appears in all current, job, and production schedule bills of material (BOMs). An end item always has a low-level code of 0. Items in the next level of the BOM have a low-level code of 1, the next level is 2, and so on. MRP processes items in order by low-level code, and processes an item only at its lowest-level code. You should update the low-level codes by running the Current Bill of Material Processor and the Job and PS Bill of Material Processor before you run MRP. See the Low-level Code field help topic for more information.

Routings

MRP does not directly factor operation duration times into its planning logic. However, when planning released jobs, it does use the start date of each operation to backward plan the materials required at the operation if the Plan Materials at Operation Start field is selected on the Planning Parameters form.

Also, if you use the Lead Time Processor to generate lead times for manufactured items, the operation's Run Duration, Move, Queue, Setup, and Finish times will be used in calculating lead time. Therefore, accurate information in your routings is important for successful MRP planning.

Item Lead Times

MRP uses the item lead time to determine the due dates on planned orders it creates to satisfy requirements, planning backward in time from the date the item is needed. Typically, you use the Lead Time Processor to generate the lead time for manufactured items automatically from information including the item routing's move, queue, setup, duration, and finish times and the average hours in a work day.

On-hand Inventory and Receipts

MRP calculates the on-hand inventory quantity at the beginning of the process as the total on-hand quantity (that is, on-hand - Qty Reserved for customer orders) at all nettable stockroom locations across all NON dedicated-inventory warehouses at the site. A dedicated-inventory warehouse has the Dedicated Inventory field selected on the Warehouses form.

Receipts (also called "planned supplies") include expected incoming quantities from jobs, production schedule releases, MPS receipts, purchase orders, and transfer orders. If the planning parameter Check PO Requisitions is selected, purchase requisitions are also considered as receipts.

The system considers on-hand inventory and receipts in determining the net requirements for an item.

Transit locations must always be non-nettable for site-to-site transfers. Cross-site transfers show up as receipts in the To Site, so the transit location has to be non-nettable so that the quantity isn't considered twice by MRP; in the beginning projected on hand and as a receipt.

When performing warehouse-to-warehouse transfers within a site, the transit location used by those must be nettable. MRP ignores transfer orders within a site; that is, they do not show up as a receipt or requirement. If the transit location used by these transfer orders were non-nettable, then the quantity would disappear while in transit and the system would not use it for planning; for example, the system would create a PLN to cover a requirement when the quantity in the transit location covers it. Therefore, transit locations used by site-to-site transfers should be non-nettable. Those used by warehouse-to-warehouse transfers within a site should be nettable.

Independent Requirements

An independent requirement is a demand for an item that does not originate from another requirement. Forecasts, customer orders, and demand transfer orders are independent requirements. MRP starts by planning independent requirements and generates "dependent requirements" for the next levels in the item's BOM.

Master Production Schedule

The master production schedule (MPS) allows you to control production of key end items to help you protect your schedule from fluctuations in order-based demand (forecasts, customer orders, parent job orders, etc.). MPS is a manually created, anticipated build schedule for an item. You create it based on your expectations of demand and your estimation of resource capacity.

When you run the MPS Processor, planned orders are created for MPS item requirements that are due outside the MPS plan fence, but not for the components in the MPS item's bill of material. When you run MRP after running MPS, MRP does not create planned orders for the MPS end item, but does pass those requirements down to the components in the MPS item BOM, creating PLNs for the components.

Information MRP Generates

The output of an MRP process includes planned orders and exception messages.

Planned Orders

When you run an MRP process, the system generates planned orders (PLNs), as illustrated in the example below. PLNs represent MRP's suggestions of how you can manufacture or purchase the item to satisfy the requirements. A PLN is not tied to a particular requirement.

You must examine each PLN and firm it into a real job order, purchase order, transfer order, etc., as you deem appropriate. The item's Source field (as defined on the Items form) determines what type of receipt the PLN will firm into (Manufactured=job order; Purchased=PO; Transferred=transfer order). You can firm PLNs on the Planning Detail form or on the Material Planner Workbench.

NOTE: On the Shop Floor Control Parameters form, you can select the Schedule Planned Orders field to specify that the Scheduler consider the MRP planned orders as demands that must allocate resources (thus creating a more realistic scheduling simulation).

Exception Messages

When certain situations occur within the MRP process, such as when the on-hand quantity drops below safety stock, or when a planned receipt is no longer needed (or needs to be moved in or out in time), the system generates a warning/informational alert called an exception message. You must review these messages and take the appropriate action. You can review exception messages on the Planning Detail form or on the Material Planner Workbench. See About Exception Messages for a description of each message that may be generated.

Reports

After running MRP, you can use the Material Planner Workbench or the Order Action Report to determine the job orders and purchase orders you must generate and release for a given item to be available when needed. Use the Exceptions Report to print a list of all items for which MRP generated exceptions. This is basically the same information you can view on the Planning Detail or Material Planner Workbench forms, but may be easier to use as a tool for responding to the exceptions.

Multi-Site MRP Planning

The system can replicate MRP planned transfer orders to the supply sites in your multi-site environment.

You must set up replication rules to allow a supply site to "see" any demands coming from the site that initiated the MRP process. See Setting Up Planned Transfer Order Replication for more information.

Steps and Daily Procedures

See MRP Steps for the general MRP business process and related procedures.

Comparison with APS

APS is an alternative planning mode also available in SyteLine. Unlike MRP, APS considers resource capacity and shifts when planning a demand. Also, APS plans demands by order priority, completely planning a single demand through its entire BOM before determining whether capacity is available to plan the next demand. APS is a more accurate and realistic planning method than MRP; however, it may require more thought about how to set a variety of additional planning parameters. APS also requires you to provide accurate routing information to achieve an accurate plan. SeeAPS Overview for more information about the APS planning mode.

Example MRP Plan of a Bicycle End Item

To understand the planning process MRP uses to satisfy requirements for an item, consider a simple BOM for manufacturing a bicycle. In this example, we have an end item Bike that is made from a Frame subassembly, a Wheel subassembly (2-per), Grips (2-per), and a Seat subassembly. In the graphical representation below, the number in parentheses represents the low-level code for each level in the BOM.

Example MRP Input Data

For this example, assume this starting data:

Fixed Lead Time for Bike: 3 days
Current date is 4/5
On-hand inventory for Bike: 50
Safety stock for Bike: 20
Forecast for Bike: 500, due 4/11 (for this example, we will assume this date is within the Forecast Look Behind/Look Ahead window)
Customer order: 200, due 4/20
Purchase order for Grips: 500, due 4/6

When you run MRP Planning, the system performs the entire process for one end item (and all other end items) before moving on to the next level in the BOM. The system plans all items with low-level code 0, in order by due date, and then plans items with low-level code 1, and then low-level code 2, and so on, until all levels of low-level coding are planned. For simplicity in this example, we will observe the process only for low-level codes 0 and 1.

Processing Low-level Code 0 (End Item)

Compare forecasts for the item to customer orders to determine the true net requirements. In this example, the forecast has an original quantity of 500. The single customer order in this example (quantity of 200) "consumes" that requirement down to 300. MRP will use this quantity as one of the independent requirements to plan.
Create independent requirements for the end item:
- Forecast: 300
- Customer Order: 200
  NOTE: This example includes only a single customer order and a forecast; however, other demands, such as job orders, transfer orders, and project resources, would be considered as well.
Calculate beginning balance on-hand. For this example, on hand is 50.
If beginning on-hand is below safety stock (for this example, it is not):
- Generate On Hand Below Safety Stock exception message.
- Search for planned receipts (jobs, POs, etc.), within the Job Reschedule time fence or PO Reschedule time fence, to cover the safety stock and generate the appropriate exception message (Move In Rcpt/Move Out Rcpt as appropriate). If planned receipts do not cover safety stock, generate a PLN due on the date the on-hand went below safety stock.
Process all requirements for the item. For each requirement, deduct the order quantity from balance on-hand. If the requirement is a forecast, and the Use CO or Forecast parameter is set to Forecast, deduct the full forecast quantity from balance on-hand. If the parameter is set to Both, deduct only the Outstanding Quantity (that is, the quantity not consumed by customer orders) from balance on-hand.
After deducting the requirement quantity from on-hand, if on-hand is below safety stock:
- Generate On Hand Below Safety Stock exception message.
- Search for planned receipts (jobs, POs, etc.) within the reschedule time fence to cover safety stock. If necessary, generate the appropriate exception message. If existing receipts do not cover safety stock, generate a PLN to cover safety stock and the unsatisfied requirement. The system considers the PLN as a placeholder receipt that you will later "firm" into a job, purchase order, etc. In this example, there are no existing receipts to use, so the system creates two PLNs: one to represent the quantity of the forecast (plus the quantity needed to cover safety stock) and one to satisfy the customer order:
  - PLN 1: 270 (net of 300 forecasted quantity - 50 on hand + 20 to cover safety stock), due 4/11
  - PLN 2: 200 (to cover customer order), due 4/20
On the Planning Detail form, the plan for the Bike item would look something like this:

NOTE: Depending on the due dates of the demands and the setting of the Days Supply field for the item, these PLNs may be consolidated into a single PLN with a quantity of 470.

Pass PLNs for this item down to the component materials in the next level of the BOM. This step "explodes" the requirements for this item down to the next level of the BOM to create the "dependent requirements" for the components.

Pass any PLNs created/updated in the previous step to the current BOM, creating "parent planned orders" (PPLN requirements) for the appropriate components. In this example, the system creates these PPLN requirements:

Component	Requirements	Due Date
FrameAssy	PPLN 1: 270 PPLN 2: 200	4/7 4/15
WheelAssy	PPLN 1: 540 PPLN 2: 400	4/7 4/15
Grips	PPLN 1: 540 PPLN 2: 400	4/7 4/15
SeatAssy	PPLN 1: 270 PPLN 2: 200	4/7 4/15

NOTE: The component requirements' due dates reflect the parent requirement's due date minus the end item's lead time, counting only manufacturing days as defined by the MDAY calendar.

Pass any job receipts identified in step 5 to the job BOM (if it exists; otherwise pass to the current BOM), creating parent job requirements (PJOB requirements) for the appropriate components. In this example, there were no job receipts for the end item.
Pass any production schedule receipts to the production schedule BOM (if it exists; otherwise pass to the current BOM), creating parent production schedule requirements (PPS records) for the appropriate components. In this example, there were no PS receipts for the end item.

Repeat the above steps to plan the next item. If this is the last item with low-level code 0, move on to planning the items with low-level code 1.

Processing Low-level Code 1 Items

For simplicity, the following process is summarized for all low-level code 1 items; in the system, the steps would be repeated for each low-level code 1 item individually.

Compare forecasts for the item to customer orders to determine the true net requirements. In this example, there are no forecasts for any of the low-level code 1 items.

Create requirements for the item. Requirements for items in the bill of material were passed down from the end item. For this example, the following requirements were passed:

Component	Requirements	Due Date
FrameAssy	PPLN 1: 270 PPLN 2: 200	4/7 4/15
WheelAssy	PPLN 1: 540 PPLN 2: 400	4/7 4/15
Grips	PPLN 1: 540 PPLN 2: 400	4/7 4/15
SeatAssy	PPLN 1: 270 PPLN 2: 200	4/7 4/15

Calculate beginning balance on-hand. For this example, there is no available on-hand inventory for any of the components.
If beginning on hand is below safety stock, generate exception messages and safety stock PLNs as described above in the Processing Low Level Code 0 section.

Process requirements for the item, as described above in the Processing Low Level Code 0 section. Create PLNs to satisfy each unsatisfied requirement:

Component	Requirements	Resulting PLN
FrameAssy	PPLN 1: 270 PPLN 2: 200	PLN 3: 270 PLN 4: 200
WheelAssy	PPLN 1: 540 PPLN 2: 400	PLN 5: 540 PLN 6: 400
Grips	PPLN 1: 540 PPLN 2: 400	PLN 7: 40 PLN 8: 400
SeatAssy	PPLN 1: 270 PPLN 2: 200	PLN 9: 270 PLN 10: 200

NOTE: For the Grips component, PLN 7 is only for 40 because the purchase order for 500 satisfies 500 of the PPLN requirement.

On the Planning Detail form, the plan for the FrameAssy item would look something like this:

The plan for the Grips component would look something like this:

Pass PLNs for this item down to the component materials in the next level of the BOM. This step "explodes" the requirements for this item down through the BOM to create the "dependent requirements" for the components.
- Pass any PLNs created/updated in the previous step to the current BOM, creating "parent planned orders" (PPLN requirements) for the appropriate components. In this example, the system passes PPLN requirements down to the low-level code 2 components.
- Pass any job receipts identified in the previous step to the job BOM (if it exists; otherwise pass to the current BOM), creating parent job requirements (PJOB requirements) for the appropriate components. In this example, there were no job receipts for any components.
- Pass any production schedule receipts to the production schedule BOM (if it exists; otherwise pass to the current BOM), creating parent production schedule requirements (PPS records) for the appropriate components. In this example, there was a production schedule for the Grips item, but the Grips item has no components.
Repeat the above steps to plan the next item. If this is the last item with low-level code 1, move on to planning the items with low-level code 2.