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?
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:
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.