Understanding MRP Results

The MRP Engine in R+ operates similarly to any other MRP engine. Basically, it takes any demand against a parent part and generates a corresponding recommended order. If the parent part is nonbuffered, the recommended order will be for the same amount as the demand. If the parent part is buffered, the recommended order will not be generated until the Net Flow for the parent part enters the Yellow or Red Zones. The supply order quantity will be Top of Green - Net Flow.

The recommended order will generate subsequent demand against the child parts for that item in the necessary quantities dictated by the Bill of Materials for the parent part. Recommended orders will also be generated as necessary on the child parts. This process will flow down through all of the child parts on the BoM.

There are multiple ways to set up the MRP engine in R+. You can let the system just generate recommended orders that you will review and accept where necessary. Each accepted order will trigger demand and supply orders down the BoM. You also have the option to turn on various forms of auto approval in the MRP process, which can automatically generate and approve supply orders for Non buffered or Min-Max parts.

For more information about enabling MRP and the MRP settings, visit the Site Administration > Processing page.

However you configure the MRP engine, it can be a little complicated to track. Here are some guidelines and tips to tracking MRP orders and interpreting MRP results in R+.

Tracking MRP-Generated Orders

Source

The Source column will be important when tracking demand and supply orders back to the corresponding demand/supply orders at the parent part. When MRP is turned on, you will see data populated in the Source column in the All Activity of the Workbenches and in the Pending Orders screen.

Demand Tracking

One of the easiest ways to track the source of an MRP-generated order is to review the part's All Activity details. In the example below, we are looking at child part PPA. In this view, we can see many Order Numbers that are R+ generated (these are also known as LinkCodes). When a demand (in red or gray) has a LinkCode, that means it was generated via the MRP engine and can be traced back to a supply order at the parent part.

For each demand on a child part, the Source should be a supply order at its immediate parent. In the Source column, this means that you will see the order number, part, and location of the parent part for each of the demands on the item. This source relationship will always be one level apart. So FPA is the next level parent part for PPA. It is not necessarily the finished good in the BoM.

Supply Tracking

R+ will generate a temporary LinkCode for all supply orders generated via the MRP Engine. Unlike the demand, a LinkCode on a supply order does not necessarily mean that is was generated via the MRP engine. A temporary LinkCode will be generated for any recommended order in R+ that has not yet been committed and received the order number from your ERP system. You will need to check the Source column on the supply orders to confirm if they were generated from the MRP engine.

On any supply order on a NB part, you will be able to view the supply order at the parent part that caused the supply order on the child part. This also means that the source on a supply order for a NB part should correspond to an MRP-generated demand on that same part. When tracing supply orders you will notice that a supply and a demand order at the same part should contain the same source information.

In the example below, you will notice that the demand order with the Order Number beginning "82a194b0" has the same source information as the supply order with Order Number beginning "ef9e16d7". The way to read this is: "Work Order 550001 at parent part FPA caused a demand against child part PPA, which in turn generated a corresponding replenishment order for child part PPA."

You can view the same Source info in the Pending Orders screen. In this view, you can see that there is also 1 order for part 201-1005 with no source. Instead it just says "Replenishment Order". This means it is a Buffered part and does not retain the source info of any specific demand orders. You can only track order numbers through the MRP engine with NB parts.

Order Quantities in the MRP Engine

Like all MRP Engines, R+ respects the Bill of Material when generating supply orders. This means that it also respects the supply quantities necessary for each part in the BoM.

In some cases, you will have a 1-to-1 relationship between the parent and child in a BoM. This means that it takes 1 child part to make 1 of the parent part. In this case, the demand quantity and supply quantity for orders on Nonbuffered parts should be the same. The running balance should net out to 0 on these NB parts. Look at the example of Parent part FPA and Child part PPA below.

Parent part FPA has two open supply Work Orders. Order Number 55001 has a quantity of 48. Ornder Number 55002 has a quantity of 24.

In the BoM for parent FPA, we see that it takes 1 of PPA to make FPA.

This means that when you look at the demand on the child part PPA, the quantity in the Work Orders for this part are the same quantities as in the supply orders for the parent part FPA. The supply orders generated out of this demand on PPA will also be the same quantity to net the running balance to 0.

Running Balance for non-buffered parts is ideally always 0. You can see a running balance greater than 0 if the part has a significant minimum order quantity compared to the demands placed on it. You can see a running balance less than 0 if there are demands outside the demand order window for the NB part.

Using the "Created (UTC)" Column

You can see the Source information as well as “Created (UTC)” column in the All Activity view.

You know that a child part could have multiple dependent demands placed on it from the same parent or multiple parents. You can sort by “Created (UTC)” column to understand the sequence in which MRP generated dependent demands on the child. When you sort on this column, the running balance shown will be out of alignment.

MRP starts off with the inventory of 2890 and it first saw the two demands – 1000 and 2000 which resulted in a negative running balance of 110 and it created a supply order for 110. Next it saw a demand of 48 and hence created a supply order for 48. You can walk the remaining steps and finally come to conclusion that MRP generated matching supply orders and brought the running balance to 0. Running balance mentioned in the above lines are the internal MRP calculations and not the one displayed.

You must re-sort on the Date column to get back to the original view to see the running balance correctly.

What is a LinkCode?

A LinkCode is an R+ generated ID for an order in R+. These are generated for all supply orders and are usually temporary. When you export the pending orders from R+ you get these temporary order numbers. Roundtripping happens when the next time supply order file is imported, and the pending orders are replaced by the committed supply orders from the ERP system with ERP supply order numbers. While roundtripping you have two options. You can use the temporary pending order number that R+ gave you as the LinkCode in the supply order file to track an R+ generated order that was approved and is now in your ERP system. If you provide this, then R+ will continue to show the source information. If the LinkCode is not provided by you in the supply order file, then R+ will not show the source information.