Hi, I need some help with the Move/ queue hour feature. I am a relatively new user of Epicor ERP. In our plant, we assemble multiple sub-assemblies at the final assembly. We want all the sub-assemblies to be ready one day before the Assembly operation. I found that all the sub-assemblies have a “fake” operation at the end of their method to add up 24 hours in scheduling to get this offset. I was wondering why we cannot use move hours instead of this fake operation. I did not find any documentation about why those methods were set up like this. Do you see any issue of using move hours to get the offset? What is the standard way to handle this?
Any suggestion will be appreciated. Thanks in advance.
move/queue time is set at resource level and operations linked to that. My suggestion is not much different to what you have. I suggest that the first operation on your top level is essentially the fake operation (and remove it from each subassembly) that has either queue time or move time (doesn’t make any difference) and all of your subassemblies related operation will be this new operations seq #, that way they will be all linked and finish at the same time, then the 24 hours will start. I hope that made sense.
regards,
Paul
Move and queue hours have some “smart” things to them that can make them tricky to actually use and know what you are going to get. Things like if it’s the first or last operation, or is next to non-working days or times. It’s probably the easiest and most consistent the way it’s already set up. Theoretically it should be like you describe, but in practice, it’s often not what you would expect and can be frustrating. In my experience anyways.
There is a configuration flag which determines if these times take into account the resource calendar or not, which can confuse things a bit. Also it is important to understand that these times are inserted into the Job’s schedule they do not prevent the resource from being scheduled to another job during the gaps.
Thanks, everyone for the suggestions. @PaulMorgan that is exactly I am doing while updating the methods. thanks for sharing your thoughts. @Banderson I get that the “Smart” things behind the move/queue hours rules sometimes may create confusions, but all these rules kind of make sense. @Mercer_Sisson I do want to schedule other jobs at the move hour gap for a resource. So I think it will not be an issue. Thanks for bringing this point.
I found that some of our resources were using move hours and others were using the “fake” operation to get the offset. I am trying to have a consistent approach to get the offset. I found it’s easier to control the offset in resource level rather than the operation/ method level. But as it seems like it is not much popular feature among all, I need to reassess my thoughts. I appreciate if anyone else can share your experiences about it. Thanks a lot all of you.
Thanks for the suggestion @Gil_V Yes, it will work in most of the cases. But if I need an offset between Operation 20 and operation 30 of a Part, then I think Move hour/ Fake operation will be necessary.
Btw, can you tell me how can I set the Receive time system -wide? I thought I had to set it for every part.
It’s a setting on either Site or Plant, I believe. We’re transitioning from 8 to 10, so I keep forgetting where that setting is, as it is in two different places
in the two versions.
I would like to know where it is too. The only place I can find receive time is on in part entry, or part class. From what I can tell from help, those are the only places as well. (although sometimes help misses a thing or two).
I can tell you where it is in 8, but I am not sure how that relates to the version you might be using. We’re going to 10 in a month, I just haven’t gotten to
that setting yet.
It is a setting on Part Class under the Plant tab.
ok, you said one transaction system wide, so I thought you meant it would change for everything. If you have multiple part classes, you would have to change for each part class. Still better than every part.
Yeah, there are about half a million settings that affect planning and scheduling. Sorry about the incorrect info. Admittedly, if you have a lot of part classes, it could take several transactions to initiate the change.
Also, several settings in Epicor are of the type that they apply when new items are added - they may not automatically roll back into existing items. Unsure if this is one of those types of fields.
Thank you all for your input. Here’s the summary of my understanding based on your comments and further testing:
Receive time- Part specific offset, applies offset at the end of the part manufacturing.
Move time – Resource/ Resource group specific offset, applies everywhere in the method unless the operation is the last one for a job. Works fine with sub-assemblies. It ignores non-working days while counting Move hours. Say, you need 2 days offset between operation 1 and operation 2 and you set up the resource to have 48 move hours. If the scheduling machine schedule the operation 1 on Friday, it will schedule operation 2 on Tuesday as Saturday and Sunday both are non-working days.
Queue time - Resource/ Resource group specific offset, applies everywhere in the method unless the operation is the first one for a job/ sub-assembly.
Send Ahead offset – Method specific offset, I found sometimes it works, sometimes doesn’t. I couldn’t figure out any pattern of error.
Offset by having dummy/ fake operation – Method specific offset, always works, but difficult to maintain consistency due to method specific.
In our case, it seems move hour should work great. I am interested to give a try with it to get than offset consistently.