Deleting unfirm jobs

As part of preparation for go live of Epicor 10, we are doing multiple tests of MRP. One of the things we encounter is the need to delete the unfirm jobs for a given part number.

Normally, we use the Job Entry screen and bring in the list of jobs that we want to delete. Then, by repeatedly hitting the Delete (X), the jobs are removed.

In Epicor 10, that doesn’t work. We can’t delete the job without firming it first.

What are we doing wrong here? Does the ability exist to delete selected unfirm jobs without firming them first?

Why do you want to delete them? Epicor will just rebuild them once MRP Runs again, and again and again. It will also Delete them once they are no longer needed. I usually dont even mess with Unfirm Jobs, I set my Demand and Forecasts properly and let them exist.

Tech Ref MRP Guide:

1 Like

Hypothetically, we are testing. We run MRP on a given part, are not happy with the results, and wish to delete the unfirm jobs and rerun. (Net change on a single part).

My question is how you delete them, not why you delete them.

Can they be deleted without firming?

like @hkeric.wci explained that you ignore them, unfirmed they impact nothing. The question truly is why would you feel the need to delete them? Read the MRP guide supplied, or elaborate on the issue you are facing that you think you need to delete them for.

Okay, I’ll type out the full explanation so everyone understands why someone would want to delete a set of unfirm jobs.

Let’s say you are testing constraint. You change a part parameter - in this example, you take one or two lines on a PO and unlock the dates and quantities, because you want to see the suggestions change due to a couple of deliveries that can be altered.

You don’t want to run full MRP, because you only need to test one part.

Rather than deleting ALL unfirm jobs, you only want to delete the unfirm jobs on the part you are going to rerun Net Change MRP, so you can quickly evaluate the suggestion changes based upon some material that can be moved to an earlier date.

Since you’re in a test environment, you’d like to prove the workability of the process prior to going live.

So, in order to not have to wait two hours for a full regenerative MRP run (to delete ALL unfirm jobs), you’d prefer to just delete a small subset of unfirm jobs, and run net change MRP on the selected part number.

When doing that, you realize that, in V10, you have to firm an unfirm job or deletion is not allowed. Since this differs from the current version of the software that is in use (in this case, V8), you reach out to the community to ask if anyone else has encountered this.

Instead of getting help, you get folks telling you that you don’t need to do what you are attempting to do.

I’ll give you another reason why you would want to delete a subset of unfirm jobs. When looking at shop load, it is important for a shop to understand when the load represents actual released jobs versus unfirm jobs. It does no good to move manpower around for jobs that aren’t in the factory. So, in order to get a clean look at what the released shop load is, you delete a set of unfirm jobs planned to start in the near term to properly answer that question. The canned load reports do not differentiate those hours, which is one of that report’s biggest weaknesses.

Would you want to commit a department to overtime/weekend hours when the load represented is not actually in the shop? I wouldn’t, so I’ll spend 15 minutes and delete imminent unfirm jobs so I can properly direct the shop to where their resources are best spent.

I’ve given a couple of valid reasons why in our particular case, we would want to accomplish this.

Now will someone please answer the question and stop telling me that I don’t need to do what I am trying to do?

1 Like

Bravo! :sweat_smile:

That was a helpful explanation. Sometimes it’s hard to tell when to outright give a direct answer because we don’t want to give answers that perpetuates bad practices etc, so in our best intentions we try to do a mix of each. There are a mix of new comers and old schoolers here and we’ve seen some eye raising practices and try to curb things like that. Not saying in your case this is true at all.
I sat in the production control manager seat and ran plant scheduling for 10 years and dealt with all those issues and never had to delete unfirm jobs to get what you described, that’s why i chimed in to support the previous posters answer. That being said, one way i know you can get around this is to change the setting in company configuration to allow changes to engineered jobs. Uncheck that flag and you can delete away to your hearts content. I mean it is test right?

I should add this works for me in my version (10.1.500). Should it not in your version, I would build a couple DMT templates via whatever method you choose (SQL, BAQ etc…) and Firm them in one, delete in the subsequent one.



and because i just can’t resist :rofl:

We are in a test environment. We just have our full live dataset in it.

Does checking this Prevent Changes checkbox prevent the MRP process from deleting unfirmed but engineered MRP jobs also?

In the spirit of direct answers, it depends on how you run MRP.

If you run “Net Change”, MRP will not delete unfirm job. If you run “Regenerative”, MRP will delete all unfirm jobs, regardless of the setting of Prevent Changes.

That Prevent Changes checkbox means that if a job is in an Engineered status (JobHead.JobEngineered = TRUE), you cannot make method or demand changes to it (you have to un-engineer it first).

Net change definitely deletes unfirm jobs. I did that a couple of times today. It just deletes them only for the items chosen (by specifying individual parts). I have not tested on a part class specification, but every part I’ve planned via net change MRP does remove unfirm jobs and create new ones.

I know this for a fact because I occasionally have to change a part setting in order to correct the plan. The jobs created through net change have the new setting, and the old jobs go away.

Net change deletes unfirm jobs, but doesn’t always recreate them. One situation where it won’t recreate them is if they’re for a configured part, and the orders used an older version of the configurator. Probably only something you’ll run into during development, but it confused me for a bit. I was actually looking at this thread earlier today trying to figure that out!

1 Like

Good detail to point out Kevin! I think the configurator makes everything a little more complicated.