Hello All;
We have Resource Groups that were established long ago, and someone created 20 or so Resources within those groups. Example, we have a Resource Group called PACKAGING and then resources under it, PACK1, PACK2, PACK3…
We are just now getting into using the scheduling functions better and I would like to inactivate these Resources since we cannot delete them.
What is the best way to do this?
There are active Jobs that have these Resources on the Operations, so if I inactivate the Resource, what happens to these Jobs?
Do I need to modify All Jobs to use the Default Resource in the Group PACK1, via a UDASH?
If I just inactivate all the Resources I don’t want, could I just do a Global Reschedule and the Jobs will see no Resource and default the operations to PACK1 or will this cause an “Invalid Resource” error. I have see than error in testing.
Any guidance appreciated, from someone who has set a Resource as Inactive.
You need to change the scheduling resource for any open job, especially if you are running MRP, before you inactivate the resource. If you run MRP and have resources for an open job that are inactive, it will hang up MRP. You should update your methods as well.
George - Why not set the operation to use the resource group only, both on active jobs and on MOM’s (for future jobs that MRP would create)? And let those resources sit in the resource group until they’re needed down the road?
Having recently done this having appeared to have successfully tested in a test instance without thinking it fully through, causing the MES to do a massive “computer says no”, and then having to manually reschedule lots of jobs to use active resources a few things to note
It is dependent on how you have configured scheduling, if you just schedule based on the resource group as Andris suggests, Epicor will typically try and fill resource 1 and then fill resource 2 on any given day in resource alphanumeric order - so in theory if you have pack 1-20 and the load never fills any more than pack 1-15 - you can make pack 16-20 inactive without issue. If you do a query/baq on the resourcetimeused table you can see what open load is against each resource - if a resource has no load and is not specifically called out on production route then you should be able to make it inactive without impact on released jobs.
To get an idea of whether a resource is specifically called out on a production route/mom do a query/baq on the partopdtl table - you could then identify any route with that resource and use the DMT to mass update and replace with a resource that is still active
Another way of doing this is a more staggered and cautious approach is to do step 2 and then decide when you want the resource to become inactive and as an example on that resource put two weeks worth of non working days in that resources calendar from that date. This means E10 will not schedule any work against that resource on those days, and once you hit the period you entered non working days for, check that there are no remaining open jobs using that resource, and can make it inactive. Two weeks is an example, it really depends on how far you/MRP plans and releases work.
Assuming you have a small number of active jobs and you have done step 2 you can ignore step 1 and step 3 and just make the resource inactive - then run a query against resourcetimeused for the inactive resources with current jobs - use that query as a list of jobs that you need to manually reschedule within job manager/entry - you might need to run on the ability to schedule in the past in company/system config (can’t remember which) if the original job start is in the past and you wish to keep the integrity of that - for example an overdue job.
From bitter experience, as our system is configured global rescheduling does not fix making an active resource with load resource inactive - there may be some other config that does allow if to fix this.
There is a menu option under Engineering > General Operations called “Mass Resource Group Replace.” I don’t know if that will be helpful. I thought we used it for the resource, but now I remember we were changing resource groups. I hope it helps some when you’re trying to change the method master. We call them BOMs but I think a MOM is the same thing.
Yes, thanks for the information. I am looking for a way to mass move all jobs off of resources, kind of like moving the Resource to another Group, but Resource to Resource.
Someone long ago created all of these, and when the scheduler runs, it overflows onto the next Resource. I need to move all resource Jobs to the Main Resource to be able to inactivate the others.
That is a great tool for sure, but it is to move Groups. Under Resource Entry, there is also a button to move the Resource to another Group, but nothing to move all Jobs from Resource to another Resource.
James;
Excellent information! I think that #3 would not work well, as it would schedule things way out on those “Overflow” Resources and make things late® than they are.
I thought of setting a bogus calendar on the spare resource groups and make the primary Infinite so everything would just be dropped on that one, but that does not help Jobs that are already scheduled.
In the PILOT system, I was able to do an update to change the Resource Group to the Primary on the ResourceTimeUsed Table, then run the Generate Shop Cap process again.
The Overload Informer looks right after the regen.
The Resource Scheduling Board does not show any Jobs on the secondary Resource anymore, and only on the Primary.
I think I will try this for one and see how things go. I looked at Job Operations for Resources and found only a handful that had what will be inactive Resources, but I figure when they go to schedule the Job after creating it, they will get the “Invalid Resource” error and fix the Operation on the Job at that time, so no worries there.
Not sure how MRP will react, but will test on one to see what errors I get.
Thanks all for your input. I think this would be a great Enhancement Request for 10.2.200.x to get a Move Resource to Resource function. I will submit that and get an SCR# and if you guys would, add yourselves to it for a future release.
As you say going forward that is an option but if you have active jobs assigned to a resource/resource group if you make the existing resource/group inactive you will get lots of warnings/errors on the MES. The mass update works on the partopdtl/ecoopdtl table it does not update the jobopdtl table so existing jobs are untouched.
There is no quick fix that I know of for active jobs - I think the 4 options I suggest are the best available.
