SAP planning run settings explained

Posted by feimster under PP, SAP | Tags: M61X0001, MD01, MD02, MD03, MD50, MD51, MDBT,
MRP, NETCH, NETPL, NEUPL, OM0E, OMDT, OMIQ, planning run, regen, regenerative,
RMDATIND, RMMRP000, SAP, SM36, SM37 |
Leave a Comment

SAP’s material requirements planning (MRP) functionality requires periodic updates – commonly
known as a planning run – to ensure that that data provided to the users is current and accurate.
The post describes many of the factors to consider when creating and running your MRP refresh in
SAP.

One of the primary factors to consider is the frequency with which you execute the planning run. I
have primarily worked in discrete manufacturing environments and have found a daily execution
provides a good balance of accurate and timely data for end users against appropriate use of
system resources. You may find that once a week is sufficient for your organization. I have
encountered one client who had scheduled multiple planning runs in a single day. It was (and still
is) my opinion that this caused too much churn in their MRP and that the users who had to act
upon that data were constantly confused. There were other factors at play in that case and, once
those factors were mitigated, it became clear that once a day was appropriate.

Timing of the planning run is an associated factor. I think you’ll find there is a general consensus to
execute the planning run in background during periods when user activity is low. Of course, finding
that right time can be challenging depending on the size & scope of your SAP landscape. For
many clients, I have found early morning hours to be appropriate. I strongly recommend that you
enable parallel processing. Use transaction OMIQ to define the parallel processing server and the
number of cores on that server to be used during the run. In my experience, using this option will
dramatically reduce the execution time. My personal preference is four cores.

The execution’s parameters are also a concern. As you will see described below, there are several
important settings for the execution. The most prominent is probably the way the planning run
executes (aka, the processing key). I feel that running new planning once a week and net change
all other days is a balanced arrangement. In general, new planning involves substantially longer
execution times since all materials are analyzed. Conversely, net change only acts upon those
materials that have had a significant change since the last planning run.
Advertisement

There are a number of transactions that you can use to execute a planning run – MD01, MD02,
and MD03 are probably the most commonly used. MDBT is used for creating a planning run in the
background. There are also specialized transactions for specific MRP functions like MD50 (make-
to-order sales orders) and MD51 (project systems). You can find most of these transactions in the
menu under Logistics > Production > MRP > Planning.

Each of these transactions requires you to identify the scope of the planning run. For example,
MD02 needs you to identify a plant and either a material or product group. Here are the scopes
that must be identified for each planning run transaction:

• MD01/MDBT – plant or scope of planning. For the planning runs described for background
jobs in this posting, I would encourage you to consider using the scope of planning
configuration (transaction OM0E). With this configuration you can define a sequence of
plants that will be analyzed in the planning run rather than just a single plant. It can help
you reduce the number of jobs required.
• MD02 – material or product group and plant. Check the box to identify a product
group. They can be defined with transaction MC84.
• MD03 – material and plant
• MD50 – sales order and item. Before executing, the system will display the material and
plant associated with the order and item.
• MD51 – project and work breakdown structure (WBS)

MRP Control Parameters

Processing Key
The planning run can be executed in three different ways: new planning (NEUPL), net change
(NETCH), or net change in the planning horizon (NETPL). SAP describes this as the processing
key. You’ll find this selection is the first of the MRP control parameters seen in all of the
transactions mentioned above. New planning executes a refresh for all MRP-relevant materials
even if no refresh is needed. You may also see this called regenerative planning. Net change
planning only executes if the material has been flagged as having been changed since the last
successful planning run. You are able to see whether a material has this flag. Use transaction
MD21 to see the planning file entry. Look for the “net change planning” indicator. If set, this
material will be planned. Net change in the planning horizon behaves exactly as net change except
that the refresh only executes for the planning horizon defined by either the MRP Group (if one is
assigned in the material master) or the plant. Refer to transaction OMDX for definition of the
planning horizon.

The other MRP control parameters are described below.

Create purchase requisitions

1. Always: Create requisitions for the entire planning horizon

2. Sometimes: Create only in the opening period (see definition below)
3. Never: Create only planned orders.

In other forums, I have seen the opening period described as a “release window” and I think this is
accurate. It is a affected by three time elements: one found in SAP configuration and the other two
in the material master. Use transaction OMDT to define purchasing processing time for each plant
in work days (i.e., according to its factory calendar). Planned delivery time and goods receipt
processing time are both found on the material master’s MRP2 view. GRPT adheres to the plant’s
factory calendar for work days whereas PDT does not. The sum of these three is the opening
period. Deduct this sum from the requirement date to find the opening date. With the second
option above, purchase requisitions will be created when the opening date is less than or equal to
the current date. This is the option that I typically use and recommend to my clients.

Schedule lines

1. Never: Do not automatically generate schedule lines in scheduling agreements

2. Sometimes: Generate only in opening period (see definition above)
3. Always: Generate for entire horizon
Create MRP list

1. Always: creates an MRP list unless a termination is encountered. This is the option that
I’ve always used and recommended.
2. Sometimes: creates an MRP list depending on the exception message. You have to
configure the messages that will generate the list.
3. Never: does not create an MRP list in any case. I don’t quite understand the need for this
option. Perhaps it can improve the performance of the run?

Planning mode

1. Adapt planning data (normal): executes the planning without rereading the master data
associated with existing supply elements (i.e., planned orders and purchase requisitions).
New proposals are generated and existing proposals deleted where required.
2. Re-explode BOM and routing: production-related supply elements (planned orders) where
the “fixed” indicator is not set are reevaluated to get the appropriate picture of the master
data (e.g., BOM components or routing operations). The supply element numbers do not
change and other existing supply elements are unaffected. Unless there is a requirement to
avoid re-exploding the master data, this is the option that I recommend.
3. Delete and recreate: all supply elements (planned orders and purchase requisitions) where
the “fixed” indicator is not set are deleted and recreated with new numbers. Although this
option creates a fresh new set of orders each time you run, I think it is not necessary to
discard those orders and burn through your planned order and purchase req number
ranges.

Scheduling

1. Basic dates for planned orders: for production-related supply elements, only lead time data
from the material master is used to calculate the order start & finish dates (i.e., either the lot
size dependent or lot size independent in house production time).
2. Lead time scheduling & capacity planning: for those same elements, the planning run takes
the more detailed master data that can be found, for example, in a routing to determine the
order start dates. It also calculates the capacity that will be consumed in work centers
identified in the aforementioned routings so that you can see the load in transactions like
CM01.
Advertisement

In MD01 and MD03, you have the ability to define the planning date. This date only applies to
materials that have a time-phased MRP type (R1, R2, RR, and RS in the standard system
configuration).

Process Control Parameters

Depending on the transaction, you one of several different process control parameters available to
you.

• Parallel processing: As mentioned previously, you can leverage the multi-processor

server to execute the planning run more efficiently. This option divides the calculation load
into multiple, independent processes and, in general, reduces overall execution time
significantly. It is only available in transactions MD01 and MDBT. The configuration
transaction required to define the number of processes was mentioned previously
(OMIQ). I’ve found using 4 processes to be a good balance although I have not
experimented much with performance to truly see the impact that adding additional
processes can have.
• Display material list: In most planning transactions (except MD03), you can set this
parameter to get a list of the materials that were affected by this planning run in a table
along with columns for the eight different exception classes and a count of exceptions in
each class. In dialog mode, you have to click a button to see the table and it is similar to
the one you see in MD06. You have the ability to drill into the MRP list in the same way
that you would in MD06. In the background, you’ll get the table at the top of your spool.
• Also plan unchanged components: For transactions MD02, MD50 and MD51, this
indicator behaves much like executing in regenerative planning mode. For components in
the exploded BOM that would not have been processed under a “net change” planning run,
this indicator will force an evaluation.
• Display results before they are saved: In transactions MD02, MD03, MD50 and MD51,
you can set this parameter to have the system present the results to you before they are
saved. You have the ability to add new, modify proposed or existing, or even delete
elements in these results. The elements I’m speaking of are ones that MRP has proposed
– planned orders and purchase requisitions.
• Simulation mode: For transaction MD02, the planning run goes through the motions of the
calculations through all levels of the BOM but does not actually write any of the results to
the database. You can see the material list and can even drill into the simulated results to
see what has been determined and make changes if required. Nothing is posted until you
click Save.

User Exit

For transactions MD01 and MDBT, you will find two additional fields associated with a user exit.
You can implement the enhancement M61X0001 described in OSS Note 208025 to provide more
targeted functionality in these planning runs. I have personally implemented this exit and my client
found it very useful. The first field is the key which can be created using transaction OMIX. These
keys will become effective only with implementation of the user exit. The second field is a
parameter field which can optionally be used to further refine what the key does. In the
enhancement, you can find some sample code that should give you some idea of what you can
do. Here are a few of those examples: execute planning only for material type FERT, execute
planning only for MRP type PD, or execute planning only for the MRP controller specified in the
parameter.

Other Notes

I mentioned previously that background execution is the recommended approach for the planning
run. It means that one or more jobs will be created and appear in transaction SM37. Due to
limitations in scheduling functionality, I generally create seven jobs – one for each day of the week
and each scheduled to run once a week. Six of those have a net change variant and one has the
new planning variant. If you really wanted to cut down the number of jobs, you could consider
making a customized factory calendar with six working days and assign that calendar in the start
date restrictions. This job should be scheduled to execute daily, but be sure to also select the
option “Do not execute job on Sundays or Holidays” in order to prevent the job from running on the
seventh, non-working day. Schedule the new planning job to run weekly on this seventh day.

Advertisements
REPORT THIS AD

You’ll find that you cannot create these background job variants through MD01 – the save button is
disabled. Obviously, SAP intended for you to use transaction MDBT for this activity. RMMRP000 is
the program that gets called in a background job created in MDBT. To create variants, you could
also go directly to the program via SA38 or SE38 or even create the variant you need while
creating a new job in SM36. When assigning the program to the job step, remember to use an
appropriate userid (like one intended for batch or background processes) as the executor of that
job step.

If you are responsible for data loads and leverage the SAP program for material masters
RMDATIND, make sure to set the flag for creating planning file entries. From personal experience I
can tell you that if you do not set this flag and attempt a planning run, no materials will be selected.
This is not a problem for materials created in dialog and assigned an MRP Type that is relevant for
MRP. When ND is assigned, the planning file entry is removed and the material is no longer
planned during any run.

Advertisements
REPORT THIS AD
Share this:

• Share
•

Related

Activate MRP for Plant2008/11/08In "SAP"

Optimize Your MRP Runs2014/03/08In "SAP"

SAP community network really works2013/12/04In "SAP"

LEAVE A COMMENT

Write a comment...

Comment
This site uses Akismet to reduce spam. Learn how your comment data is processed.

Archived Entry
• Post Date :
• 2017/06/15 at 16:43
• Category :
• PP, SAP
• Tags: M61X0001, MD01, MD02, MD03, MD50, MD51, MDBT, MRP, NETCH, NETPL, NEU
PL, OM0E, OMDT, OMIQ, planning
run, regen, regenerative, RMDATIND, RMMRP000, SAP, SM36, SM37
• Do More :
• You can leave a response, or trackback from your own site.

Create a free website or blog at WordPress.com.