The problem is: we sometimes change the part that should be used as a standard, but we want to use up the old part before changing the methods. We cannot call them the same part number.
We are thinking we will mark the old part for runout and setup an alternate part substitute it for the new part. However we need to change many methods once the old part has actually runout, because we don’t want the inventory of the old part to sit forever unused. So we want to have an alert sent once the runout is complete.
I am thinking a bpm for when a part is marked as runout and the QOH has gone to zero, send an alert to engineering. I am not sure where to do the condition and what type of bpm to use to ensure I’m not going to do something that’s a big performance hit on the system/transactions. Does anyone have any suggestions?
Maybe get fancy and not wait for it to go to zero but use the PartDtl to forecast a date when the old part will be consumed so they can plan for that day. Just a thought.
@Nancy_Hoyt , sometime back in E10, Epicor finally fixed this functionality. You should be able to set up your parts correctly so that the old part gets used until it is gone and then MRP will replace all suggestions with the “new” part. I had tested this back in 10.2 I think, and it was working. Before that, I had gotten confirmation that the functionality had bugs and was not working as intended.
I would dig into the alternate part functionality and test the heck out of it before doing any customizations.
And THAT might be the trigger you can use to notify Engineering… when a STK-MTL record is created for the new part, it would then appear that the old part has run out and the BOMs at that point need to be updated.
EDIT: but be careful… BPMs on the PartTran table can be VERY dangerous. You’d want to disable the BPM as soon as the notification has been sent.
Thanks so much for your input and ideas. You guys are THE BEST!
@jkane Your note is very true. Functionality has changed significantly since our upgrade from 10 to 2022. I had not retested and just assumed it still was just dialogs. Here’s results from my tests:
GET Details on Jobs:
• IF PART checked for runout and has a alternate substitute, even if method calls for old part number, get details on job pulls the alternate substitute in place of PART in the BOM if there is not enough QOH of PART
• using same scenario, but PART not clicked for runout and has alternate substitute, method does not change on mrp run to use the alternate substitute, it stays the same even if going to not have enough QOH of the PART
• IF PART checked for runout and has a alternate substitute, AND THERE IS ENOUGH QOH OF PART, get details on job uses the runout PART in BOM but provides warning when you save changes to the job (release/unrelease)
MRP jobs:
• unfirm job uses method that calls for old part number when it is checked for runout and there is enough QOH
• unfirm job uses method but replaces old runout part number in bom if there is not enough QOH
Note: Still do not want to keep old runout part number on approved methods forever. Will want to change the methods via mass part replace when runout complete. So I think we still need a bpm. I wonder if I could do a trace and figure out what is running when Epicor replaces the runout part with the substitute on a method. OR use @Hally note and look for deleted PartBin record with runout on a part checked. That might be easiest and not too taxing on Epicor. I am certainly very wary of doing a PartTran bpm ! @Mark_Wonsil , oh if only we were that good at forecasting our need…
Agree 100%! I just brought the functionality up as I knew it was working. If it were me, I would just create a dashboard or report that brought back all run out parts that have an on hand of 0. Then someone could just go and update those methods using Mass Part Replace/Delete.
The one thing that the functionality does not address though, is you have qty 5 of a run out part on hand, but the job needs 10, so it does not consume the remainder and then switch to the new part. That would need to be done manually (or through a BPM).
Yes John - that remainder could stay in limbo for a looong time. A dashboard is tempting but then someone needs to go and look at the dashboard sometimes and do something based on what they see … I might still be leaning towards sending an alert so that we are not relying on self-serve so much.
There is a point where we as ERP professionals need to push back and ask the question what is your repeatable process that you follow over a specific time frame. Instead of creating distractions to a person’s work day with aerts of all kinds to ignore… One of those SOPs would be to do the run out part check/rectify task.
If your engineering team uses the tasks side of things I would slip in a Task for them to follow up with.
Anothwr thought, is there a global alwet for run out parts, I can’t remember.? Now there’s a feature.
