I feel like I’ve asked this before or read it before but I’m not finding it… I’m hoping that by typing out my question the AI will find the post… here goes:
We want to schedule unfirm jobs and keep them locked in place… is that possible?
If we can’t schedule them, can we at least set the Job Req Date and keep it locked in place with an unfirm job?
Basically, here’s the issue: we don’t want to firm our jobs so that material changes to BOMs can update on the jobs without manual intervention. But we want to schedule it into a block that sometimes does not align with the order ship by date (aka specify the job req date or due date)
Recycle MRP jobs appears to be an option. But I remember we did this once upon a time and we had a problem with Recycle MRP jobs. I just need to dig into it again.
Our solution for the last 8 years has always been to set the ship-by date to match the production schedule. (Don’t read anything technical into my use of the word “schedule.” I just mean “when certain people think we will build that thing.”) Whereas the date we show the customer is (IIRC) a UD date field.
But I agree; you are describing a better way – ship-by is meant to be an obligation to the customer, but we should be free to schedule the job independently as we see fit.
I never saw the point in making an Idea for this, but it gets at my concept of a “slotted” schedule. (Not just scheduling but also deliberately leaving gaps that can be filled in.) It’s what we do in practice, but I see no Kinetic equivalent of this.
I didn’t say this, but we do the same as @dr_dan with keeping jobs unfirm for months, and letting MRP rebuild the BOMs.
Like you said, I also am not sure how MRP would play with locked jobs. I’ve never been eager to try recycling jobs. Perhaps that’s part of it.
Fundamentally, though, I don’t want a job to have to exist first. I want to say, "Hey MRP, when you finally make a job for this, please schedule it for this date.
…and @dr_dan answered about recycle jobs before I could finish typing…
I will be testing some changes to the method with the recycle mrp jobs enabled and ensure that the changes are reflected in the unfirm job as they should be.
The “Recycle MRP Jobs” functionality was added a few versions ago in order to make MRP run faster. Being a skeptic of things where I don’t know what’s happening in the black box, I’d be REAL hesitant to trust it to do what I want when that wasn’t even on the agenda. It will probably work most of the time, maybe even all the time… until for some reason it doesn’t. Murphy doesn’t quit.
The worst part is that we did try it out at one time and ended up deciding not to use it. I can’t remember why, though. It seems that we started using it when we were having MRP sluggishness… but we also tried different tasksets on different nights so that week nights were finished sooner. We also might have had a BPM in the mix that was hosing things up… We have a product configurator that might also have been hosing things up for those jobs. It’s hard to say if Recycle MRP jobs was a problem or if it just simply didn’t speed up the process like we hoped so we abandoned it. It was too long ago and I did not have any kind of post-mortem or anything where I documented all my thoughts and efforts. On that topic, I should do that more.
