Same Part, Same Op, Multiple Resources

We have parts that we print.

Right now I have 1 operation for Printing. I have multiple resources inside a resource group for that Printing operation.

The issue is our printers are not all identical, and parts are color corrected for specific printers. This means some parts can only be printed on printers A and C, some on B, C, D, etc.

This can also change over time. A part might start out only color corrected for one printer, then we may do the work to color correct it for other printers at a later date.

We need an easy way to maintain what parts can be run on what resources, and for it to be easy to know which printers a certain part can be printed on when we process jobs.

People have tried all kinds of wonky things like putting data in the part description, manually adding and removing data tags, etc.

What I am looking for is an actual solution that is integrated into Epicor. Right now our use of the Resource, Operations, Part Revision, and Alternate Method functionality ranges from simple to non-existent.

I am wondering what the Epicor intended method would be to handle this situation, or if some kind of custom solution would be best.

do you have a resource group for each printer (A,B,C or D)?

Right now no, 1 resource group, with each printer inside that group.

Do you guys manually make your jobs or do you use MRP to create jobs?

Mostly MRP, we do use Quick Job Entry sometimes when we need to.

When MRP creates the job, do you always run it on the printer that it assigned to the method?

do you use Capability under Production Management >> Scheduling >> Setup?
There you could have a capability for each of your various combinations and then in the BOO chose the correct subset of printers.
Then when you finalize the color correction for a new printer then you would modify the capability requirement on the print op of that BOO.

1 Like

Eric’s response echos what I feel about the question you are posing. I don’t think there’s any one way that is more correct than another to accomplish what you are trying to accomplish.

I just keep thinking of all the things you could do to try and set up BOMs accordingly.

Resource groups, capabilities, etc. But at the end of the day I don’t know how those things work with MRP since you use MRP for most your jobs.

If you want it to run on printer A instead of B for the day, how would you tell MRP to do that.

I imagine that since your lead times are low you aren’t scheduling jobs on printers, is that correct?

So you aren’t using capacity calcs or anything like that?

We do not use Capability. We do not use any of the Epicor scheduling functionality at all, really.

I feel the same way: Lots of ways to accomplish this, which is the reason for me posting about it.

I’m not looking for a solution, I was really just trying to get pointed in the right direction, as right now I feel like there are too many directions I could go, all of which would be fairly new territory for me.

Capabilities will work for this, but whether you schedule finitely or infinitely may affect which resource is specified. I have seen jobs with capabilities that are scheduled infinitely on one resource change to another resource (in the capability) when scheduled finitely. We’ve only used capabilities in a very limited fashion, and we definitely have more to learn in this area.

1 Like

That’s the crux of automation. You have to make it so the system can tell you which printer you should be running on, not the other way around. No matter what you put in place, if you deviate from the rules, automation will break down.


yup… I think this is more about human organization though. The OP wants a human to know what printers a product can run on.

I am starting to lean more to assigning a UD field to the part because I don’t feel like we need to add in the complexity of resource groups and capabilities and scheduling and capacity etc just so a human knows what printers a product can run on.

I like to replace automation with documentation because if you can’t document it, you can’t automate it. So…

That’s the crux of documentation. You have to make it so the system can tell you which printer you should be running on, not the other way around. No matter what you put in place, if you deviate from the rules, documentation will break down. :wink:


Yes a UD field is always an option, and I might do something like that short term, it really isn’t the direction I want to go though.

As I learn more about Epicor, I am finding it is usually better to bend our process to play by Epicor’s rules rather than to bend Epicor to conform to the way we want to do something. This is especially true when you consider automation, like Brandon said. Ultimately I would like to use Epicor to schedule, so I would like to start down a road that sets me up for success with that in the future.

I’m with you Garret, I just didn’t see you wanting to use scheduling or anything of the like.

I find it just as worthless to try and use built in Epicor functionality that is built for things like scheduling and MRP, etc. for an objective that doesn’t revolve around those processes.

If you intend on this being used for scheduling, MRP, capabilities, and you are going to use internal Epicor tools then yeah by all means you should use built in epicor functinality. But if this printer question something that you don’t want to blend into those processes I don’t know if I’d go about changing a bunch of methods and prioritizing it to meet this objective.

Yes, in my case here, most (If not all) roads lead to Epicor.

While right now we have people who make the determination of what jobs run on what printer and when they run, I do not want that to be the case forever. I would like Epicor to do at least most of that work.

The extra crux here is that all parts cannot run on all resources, so it makes it tougher to make those determinations.

Right on!

So if you want to at least call out one primary printer resource you could do that in the part method. In the scheduling resources for the operation there are three options.
Capability (which it doesn’t sound like you have), Resource Group and Resource only one of these should be filled in. Typically the Resource Group will default when the operation is added.

To indicate a specific printer resource add that resource in the Resource field, then remove the Resource Group. Now the job and job traveler can indicate which machine to use.

This can be then changed at the job level in an overload situation as needed prior to the job being released.

This does not require the Advanced Production Scheduling module to do this as the capabilities approach would above.

If you want to work toward using the Epicor scheduling tools this may be a good first step,

1 Like

Capabilities would require a new module license.
By defining multiple resources with a resource group you are pretty much signaling to Epicor that MRP/ Scheduling should select the first resource that has the appropriate capacity.

Obviously, your resources are not identical - why are they not broken up to either each to its own RscGrp/ Rsc and then on the MOM or Job Operation select the most appropriate resource for the part?

1 Like

That’s going to be the most difficult part. If you define all the resources that could possibly run that part, what resource is it going to schedule on?