We have a job (1 operation only) which requires minimal assembly but then has a 48 hour epoxy cure time. Looking for ideas on how to show the 48 hours on the schedule without it being tied to a resource.
Queue Hours/Move hours can only be set at the resource level and only used as an offset for when an Op can start or when the next Op can start, this is an issue as it would be the last Op on the job so it would have no effect as there is no next Op…people look to be putting in dummy Op’s to solve this issue which I don’t think we want to do.
At the part Level there is Production Prep Buffer/Kit Time/Receive Time, all of these have to do with material lead time or only the Start Date.
And you can’t have an Op that is NOT tied to a resource, so we can’t have a Cure Op to show the 48 hours
As long as it was 48 hours every time, I think you might be able to use the Move Hours on the resource group to do this, I don’t think the Move Hours block another job from starting, it just makes the current job wait the move hours before moving to the next op.
Receive Time should force the job to “finish” earlier than it’s actually needed. In this case if you set the receive time to 2 days, then the assembly op would schedule to finish 2 days before the job is due (so the parts can sit and cure).
If you want an operation to explicitly take that time, you could create a “Curing Shelf” resource set to infinite capacity with a 24/7 calendar. That way you’re not tracking/using any sort of capacity and scheduling on that resource.
Does the cure time take up space (or the floor, shelf, oven, etc.), or molds, or otherwise prevent another job from proceeding during the Cure time? If it does, in any way prevent another operation from occurring, then you might want to consider giving the operation a resource (e.g. “Floor Space#1” or “Shelf 3”) and allowing for @jkane suggestion of
We currently use ‘Receive Time’ at the part level to account for this. The reason being is cure time can vary from part to part so using the options on the resource level (Move Time, etc) aren’t appropriate.
This isn’t ideal. I have lately been thinking about the options mentioned by @tsmith and @MikeGross that would involve setting up a curing resource with a 24/7 schedule and a curing operation with the appropriate curing time specified in the MOM. Backflushing the operation when complete. I think this would result in the most accurate representation of reality.
Agree. I would set the Labor Entry to Quantity Only as it would allow for the Operation to be the last. Since the cure time is set on the estimate, you don’t need to worry about the time.
When you say “on the schedule” (and mean the production schedule), in Epicor that means it has to be on a resource. Scheduling is capacity, and capacity is resources.
What is the end result you’re looking for? If you are looking for some way to signal your material handlers when these parts can be received to stock, that isn’t (at least in Epicor parlance) a “scheduling” issue. What is the purpose of the “48 hours on the schedule?”
I think Move Time is the correct idea in this case. My guess is they need the dates to line up for scheduling purposes and that’s about it. A job should not start and finish in the same day so they need move time to push out the ending of the operation a few days from start date.
I am having a similar issue except we have 2 operations. 1st op is pouring, 2nd op is a demolding/packaging. There’s roughly 24 hours of cure time in between those 2 and i’m struggling to have that represented in the dates. Depending on the size of the job the Start Date and Final Op Date are the same if it’s a small qty job as the total operation time doesn’t exceed the hours of production in a given day, this is not reality as the product cures overnight and 2nd op always happens the next day. Larger jobs run out of production hours in a given day so Epicor splits those to 2 different days.
Without Move Time small jobs have wrong dates but large jobs have correct dates. Adding Move Time small jobs have correct dates, but larger jobs have wrong dates, this is because production happens for a full day, then move time takes up all the production hours of the 2nd day putting the final op into a 3rd day.
I have been playing around with adding an additional operation between the 2 that acts as our curing operation (with a 24hr calendar attached to the resource), and my testing has been successful in keeping dates where i want them regardless of job size. However, OPS is not going to be pleased with having to clock into another operation. Clock into Op 10, clock out of Op 10 and report qty, immediately clock into Op 20, clock out of Op 20 the following day, immediately clock into Op 30, clock out of Op 30 and report qty. Alternately i made my curing operation ‘Start-to-Start’ with Op 10 since curing happens on the first product right away, but that still requires them to clock into 2 operations at the start of the job, they’re not going to be happy.
I don’t understand Backflush in this scenario, there are no materials to backflush, i just need the operation there for scheduling purposes. I do not want anyone to have to clock into this operation to move the product to the next operation. Qty Only still means someone has to report on the operation.
I’m going through the application help for Backflushing but it’s not appearing helpful, this operation in my case has nothing to do with materials or labor, it’s just there to act as a buffer between the 2 ops.
Like i suppose i could make Op 10 calendar 24hrs and then add move time but this is not reality and then Epicor will schedule jobs in the middle of the night and likely will throw off my dates because of that.
My understanding is that backflush operations do not need to be scanned
You would want qty only if you wanted the operator to be able to select how many cured or if it needs to be the final operation, if you don’t need to do that I think backflush would be the way to go.
You are correct! Backflush operation does not need to be clocked into, it actually doesn’t even appear in MES as an operation to clock into. This might actually be the solution i needed. Thank you!
