Skip to Content

1. Abstract

In SAP, Material Requirement Planning (MRP) calculations are Time based. In MRP, scheduling determines release date / delivery date of purchase requisition (order start and the order finish dates of the planned order). Prerequisites for this is that you must define “Processing time” for purchasing in workdays, “vendor’s planned delivery time” in calendar days and “goods receipt processing time” in workdays. In case of vendor whose “In Co term” is “Free on Board (FOB) / Ex Works”, we need to pick material from vendor premises or from the boarding place and deliver at our company premises. If distance between both is huge then there will be considerable amount of “Transit Time” exist.

SAP doesn’t have option to maintain “Transit Time”. Hence, without transit time, MRP determines incorrect release date / delivery date of purchase requisition. This leads to shortage of materials.

IN THIS WHITE PAPER

This white paper discusses the issues involved in the delivery date calculations in Material Requirement Planning. This paper analyzes the behavior of MRP and different master data. The paper then considers how SAP MRP, with its combination of MRP and different master data can resolve these issues. It explores how business may find opportunities for speed (to provide timely material).

2.  Introduction to the topic

Material Requirement Planning (MRP) calculations are Time based. They work on the principle that, material should be in stock, only when it is just required, not before, not later. So it is very important to get the lead times more accurately. Scheduling is carried out in MRP after the system has calculated the quantity to be procured in the lot – size calculation. Scheduling determines release date / delivery date of purchase requisition (order start and the order finish dates of the planned order)

Prerequisites for this is that you must define “Processing time” for purchasing in workdays, “vendor’s planned delivery time” in calendar days and “goods receipt processing time” in workdays.

Backward Scheduling:

In case of Backward Scheduling, the system starts with the “Requirement Date” and then schedules backwards to determine the release date / delivery date of purchase requisition (order start and the order finish dates of the planned order)

Image1.png

In case of vendor whose Inco term is “Free on Board (FOB) / Ex Works”, we need to pick material from vendor premises or from the boarding place and deliver at our company premises. If distance between both is huge then there will be considerable amount of “Transit Time” exist.

SAP doesn’t have option to maintain “Transit Time”. Hence, while scheduling, MRP determines incorrect release date / delivery date of purchase requisition. This leads in shortage of materials.

 

3. Challenges in current scenario

Material Requirement Planning (MRP) calculations are Time based. In SAP, we can maintain

  • Processing time for purchasing in workdays either in Customizing for MRP, in the plant parameters or in the work step, external procurement.

  Image 2.png

  • Goods Receipt Processing time in the material master (Purchasing / MRP 2 View)
  • Vendor Planned Delivery time in the material master record (MRP 2 View) / Info Record (Pur Org View)

Material Master:

 


Info Record:

 

Challenges here are as below:

  • Transit time can be different for various “Material + Vendor + Plant” combination. SAP don’t have option to maintain “Transit Time” in any of the master data like material master /Info Record / Outline Agreement
  • First challenge was to develop new field for “Transit Time” in Master Data like Info Record. There is no as such option in SAP to make this development in Info Record.
  • Second challenge was to make technical changes in MRP relevant program which will consider “Transit Time” in MRP calculation. This was more complex because MRP might have different unseen implications due to the technical changes.
  • Third challenge – Due to complexity of such changes, time required to analyze, development and testing was huge that was coming around 70 Hrs. For this, business was not ready. Our project go – live was jeopardized.

 

4.  Solution

To overcome all these challenges, we identified the work around. Here, we proposed below workaround to business

  1. Use Outline Agreement – Quantity Contract:

Here, use “GR Processing time” field from contract to maintain “Transit Time”. Here, GR Processing time = Transit time (in calendar days) + Actual GR Processing Time (in working Days) as per material master. Thus, based on this GR processing time, MRP will manipulate the release date / delivery date of Purchase Requisition during MRP.

Reasons to suggest Quantity Contract are as below:

  • Contract is a master data maintained for the combination of “Vendor + Material + Plant”. So, this will be unique information for the combination.
  • Conditions from Contract will always have first preference over other master records like info record, material master.
  • Only Quantity Contract because here, we needto maintain only validity period and Target Quantity. So, there will not be any impact of this on existing business process.
  • Contract will be only for internal purpose. So, none of the contract information will reflect in any of the purchasing document to be shared with the vendors.

 

  02. Maintain Source List:

In order to pick contract conditions in MRP, we asked to maintain Contract details in Source List against the required vendor.

Reason to suggest Source List is as below:

  • This way for the vendor maintained in “Source List”, we can enforce the contract conditions in MRP.

03. Maintain Material Master:

In purchasing view of material master select “Source List”.

Reason to suggest this is as below:

  • Selecting “Source List” in material master will always prompts / compels to maintain “Source List”.
  • Without source list of material, system will not allow to create Purchase Order.

  

5. Precautions:

  1. Vendor Planned Delivery Time is expressed as calendar days (maintained by user in master data : material master data or purchase info record / Contract)
  2. GR Processing time = Transit time (in calendar days) + Actual GR Processing Time (in working Days) as per material master.
  3. Contact – Agreement type should always be of “Quantity” type.
  4. In order to avoid frequent contract modification, in contract maintain

Validity End – maintain maximum possible numbers of years from the date of contract creation.

Target Quantity – maintain maximum possible quantity.

6. Conclusion/Summing Up/In Summary

  • Without any technical development, provided workaround of “transit time” is the better way for calculation of delivery date in MRP. Thus, it will enable to bring in inventory on time to meet future demand and perform available to promise functionality.
  • The given workaround is a temporary solution. There is a scope for technical development. We can create custom field for transit time in SAP. This will help in accurate MRP calculation without any manipulation and human intervention.
  • In today’s world of globalization, companies deal with suppliers from various geographies. These suppliers can have different In co terms. Timely delivery of material is important to each business. Therefore, transit time workaround is the critical solution for all the clients.
  • Without technical development and additional cost to business, suggested workaround will enable MRP process for business in the  best possible way.
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Helmut Krueger

    Hello Vijay,

    very good explanation. The only issue seems to be from my point of view: you write: “Here, GR Processing time = Transit time (in calendar days) + Actual GR Processing Time (in working Days) as per material master”.

    But help of field “GR processing time” says: “Number of workdays required after receiving the material for inspection and placement into storage.”

    That means that the number of days entered in the field will be seen as working days. If you have maintained that field with value 85 (e.g. for 80 calendar days transit time and 5 working days GR processing time), this value of 85 days will be seen as working days. The system calclulates the date to pick-up the material at the supplier e.g. to 120 calendar days before requirement date (assumed your company has a 5-day week in plant calendar). That are 35 days earlier than you need to pick up the material really.

    How do you address this issue?

    (0) 
  2. Daniel Koh

    Interesting write up – thank you for sharing. Recently i have come across a similar situation as well. The example you have shown here assumes that transmit time is more or less constant.

    It will be interesting to also consider a scenario where the choice of transit can differ after pick up. Depending on how urgent the shipment is, users may choose to opt for say, AIR or SEA shipment, which will then give different transit times.

    How would you handle such a situation?

    (0) 

Leave a Reply