cancel
Showing results for 
Search instead for 
Did you mean: 

How to change MRP logic when POs are confirmed beyond LT

lavram17
Explorer
0 Kudos

Hello!

Due to market conditions, more and more suppliers are confirming our orders beyond the agreed lead time. As you may know, the lead time for electronic components are quite long (52 weeks, 78 weeks). Therefore, we asked our customers to provide a longer visibility on demand, so we can place our POs in advance.

The problem is that, due to allocation, our suppliers are now confirming orders beyond the lead time and outside the period the customers provided demand for.

For example, we have demand until the end of 2023, but our suppliers confirm the orders for 2024 or 2025. What MRP does in such situation is to generate new purchase requisitions inside lead time (because the existing orders were confirmed beyond lead time), and all those existing POs with delivery dates for 2024 or 2025 will have cancel requests after next MRP run.

If we convert those new purchase requisitions into new purchase orders, we will end up having excess on order quantity. Most of electronic components are NCNR (non cancelable, not returnable) and we cannot cancel any of these orders.

We were wondering if there is a possibility to change the logic or MRP to stop generating the new purchase requisitions, but generating pull in (reschedule ins) messages for the existing open orders instead. Those orders confirmed for 2024 or 2025 should be considered by MRP first. It should ask for those orders to be rescheduled in inside lead time, and not for new purchase requisitions to be created.

Have you had such a situation until now? How can we change the logic of MRP to consider the existing orders to cover the gap in demand (shortage) and generated pull in messages for them?

Thank you!

Liviu

Accepted Solutions (1)

Accepted Solutions (1)

DominikTylczyn
Active Contributor

Hello lavram17

I think your problem is not that much with lead time, but with MRP planning horizon. Purchase order confirmations in 2023, 2024 are outside of the planning horizon. Therefore MRP doesn't see them and it creates new purchase requisitions.

Typically MRP is run with processing key NETPL "Net change in the planning horizon" - the processing key is an input parameter in MRP run transactions e.g. MD01. Default setting of the planning horizon is 400 days, if I'm not mistaken and honestly it's almost never changed during implementations.

If my reasoning is correct, you can:

  • either extend the planning horizon in the plant or MRP group MRP settings,
  • or run MRP planning with the NETCH "Net change in total horizon" processing key, so the MRP planning is not restricted to the planning horizon.

You need to choose the approach - with the former one you risk that again you define too short planning horizon; the latter should solve the issue radically, but you risk performance issues. If I were you, I'd go with the total horizon and see if the servers choke or not.

Also have a look at the notes

on how the concept of planning horizon and processing keys changes in S/4HANA.

Best regards

Dominik Tylczynski

Oscar_DC
Active Contributor

I kept running into the same issue so I set MRP planning to NETCH I work for a medium sized utility, so I didn't have any server issues.

If you're in ECC 6.0 , I think you also need to look at your rescheduling horizon. I think that will dictate if you get a "rescheduling" request or if MRP creates a brand new req or planned order.

Thanks!

DominikTylczyn
Active Contributor
0 Kudos

01224e03a1874b69919eab14e401e433 Rescheduling horizon... - that's a definitely great hint here.

lavram17
Explorer
0 Kudos

Thank you for your comments.

We actually run full regen for MRP (NUEPL) for the batch job program. When our Planners run individual MRP, it is via MD41, as our system is configured to differently. MD01 will not work in our case.

Current planning horizons are 100 days, but again, only relative to net change MRP.

Any thoughts on how to solve our problem?

DominikTylczyn
Active Contributor
0 Kudos

lavram17

You should not use full regenerative planning (NEUPL) on regular basis. It's just a waste of resources. See the note 23278 - MD01, MDBT: Performance during MRP run - it says "Only use regenerative planning (NEUPL) in exceptional cases."

NEUPL plans all the materials but within planning horizon which is 100 days in your case - see the note 206666 - MRP: Control parameters during planning

You should use net change in total horizon i.e. NETCH both in the batch job program and in MD41. Alternative extend the planning horizon and use NETPL.

Also, make sure your rescheduling horizon is long enough - as 01224e03a1874b69919eab14e401e433 pointed out.

Answers (0)