Hi all,
We have raised a PO for a part that is marked as manufactured in the system. The sales order ship by date was not aligned with the due date of the PO, which is why the system suggested to cancel the PO and created an unfirm job instead.
We have a simple question though - why did the system instead not create an expedite PO suggestion?
Here are some extra details for context:
Part detail:
Part Site Planner Parameters:
One thing that can stop expedite suggestions, is the âLock Dateâ on the PO release.
May be worth a check.
Because its a manufactured part . . .
No I checked the PO release it didnât have lock dates or lock qty boxes checked.
I thought like that too, but when you change the ship by date of the sales order for after the PO due date then the cancel PO suggestion goes away and MRP is happy. I remember @timshuwy mentioned during Epicor Insights ANZ 2024 that you can place POs for manufactured parts and MRP recognises that as a valid supply to the demand. One would expect to see a PO expedite suggestion instead of a cancellation suggestion in that case.
When you changed the ship date to after the PO was due, what day exactly did you change it to? Iâm going to assume it was within two days.
Thatâs true, and once you had the right date it did that. But when the PO isnât the right date, itâs not a valid supply to the demand, and so it attempts to create one. And since your system settings say that the appropriate supply type is MFG, thatâs what it tries to do.
Is the PO directly linked to the Sales Order demand (Buy Direct on the SO Release)? Or is it just a standard PO for stock?
If the system doesnât know that this particular PO was entered to fill that particular Sales Order demand, it is looking for a way to meet the demand date and by default will say you need to make that part?
If this cancelled the PO and then created a job, this is the most likely scenario.
You can use the Urgent Planning Paramters now to switch between purchased/manufactured and then this should behave more like the OP is hoping.
@cpilinko I changed the ship by date to one day after the PO due date
@dcamlin
The good thing about my scenario is that there is only one demand and one supply. If you look at the screenshot, MRP has the ability to recognise that the PO has been placed to satisfy a sales order line that is usually manufactured. No cancellation suggestion, which should have been the case as per your scenario right? Maybe if we had a buy direct link in the previous screenshot then it would have shown an expedite suggestion instead of cancel? We try to avoid buy to order unless we are doing dropshipments because we are unable to track the stock in our warehouse using bin locations, which is a different can of worms that shouldnât be opened in this thread hahahaha
I figured that this would be the most likely reason why we see a cancellation suggestion. However, the problem with this entire methodology is that the unfirm job created a lot of other related unfirm jobs and that was all artificial demand when the real solution was just to either expedite the PO or change the ship by date of the SO.
The situation we ended up in was that because of all the artificial demand that was created due to these new unfirm jobs we ended up placing high value POs to buy materials we didnât really need.
I would argue that the problem is expecting MRP to work differently than it does. Once you set the type on the part (or the source type on the plant) that is the ONLY kind of suggestion you are going to get.
I donât think that you can set it up like that - where you decide to purchase if youâre running late but generally manufacture, especially based on the other arguments presented in this thread.
I guess where this stems from is that we usually manufacture the same part for day to day local deliveries but if we get a bulk order we tend to place the order to one of the offshore subs where we get a better cost. Therefore this part can be purchased as well as manufactured, but itâs usually manufactured. And we placed the PO because the qty was large and naturally donât want to manufacture here. Exactly where the complexity comes when you start seeing unfirm jobs for the stuff you didnât want to make because it was too costly to make in the beginning!
We have the same problem, sometimes we want to transfer, sometimes we want to purchase, for the same part. Epicor MRP has nothing to manage these types of scenarios.
Doesnât the Reschedule In Delta stop MRP from making suggestions to expedite current supply?
If my theory about the reschedule in delta is correct then itâs acting kind of like a locked PO date. In my testing (locked PO dates + days of supply) = erroneous and infinite suggestions.
As someone mentioned above, we have a NEW FEATURE in Kinetic 2025.1 where you have new options in the Urgent Planning parameters.
If an item is deemed Urgent (based on the lead time), you can now trigger the urgent option to be switched to either Manufactured, or Purchased.
Example, if the item is normally purchased with a lead time of 10 days, but the requirement is 5 days out, then you can mark it to be Manufactured. The opposite is true also⌠if it is normally manufactured but urgent, you can have it Purchased. Here are the various scenarios:
Note that we do NOT support Transfer order changes using any of these. This was in the original request, but it was deemed as ânot possibleâ for MRP to determine this, which is because of the sequencing of how MRP determines transfer orders. Note that transfer orders are ultimatly very difficult due to the fact that when you have a transfer, it actually affects TWO sites in their MRP planning, which is why this became inpracticle to implement.
| Normal Method | Urgent Method | Comments | ||
|---|---|---|---|---|
| Purchased | Purchased from different vendor | If urgent, Buy from another supplier | ||
| Purchased | Make using Alt method B | If urgent, Make instead of buy | ||
| Make | Purchase using vendor | If urgent, Purchase instead of Make | ||
| Make using alt method A | Make using Alt Method B | If urgent, make using a different alternate method | ||
That sounds like a great expansion of functionality. It would be nice if there was an option to have a part transferred if the source site has excess supply otherwise purchase. So rather than having it based on due date (urgent or not) have it based on inventory availability at the other site. Right now this has to be manually evaluated on a part by part basis which is quite time consuming.
