We have a production calendar that’s set for M-F for 10 hour days.
On some resources, we have a move and queue time of 20 hours each, so 2 days before the op, time to do the op, then 2 days after the operation.
Yet–when I look at this job that was scheduled by MRP with a start date of 8/16/19, the operation with those move/queue times is starting and ending on the same day (prod hours is only 0.20).
What happened to my move and queue times?
If you look at the job scheduling board, it looks like it doesn’t put any queue time on the first operations, and not move time on the last operations. So your start time for a 2 operation job. So your first operation isn’t adding any queue time. (which I think we both agree is asinine, considering most people are really using queue and move time to pad schedules because everyone knows things don’t go instantly from one process to another)
1 Like
When did you complete operation 10? Before or after you scheduled?
1 Like
are the operations finish-to-start or start-to-start?
@Banderson - I agree on the reason the queue time is not there for the first op, but the first op also has a move time of 20 hours, so it should have that 2 day gap before the pick operation starts, no?
@E102016 - Scheduled before the operation was completed.
@amaragni - All of our operations are set to Finish-To-Start
fudge…
what is the move/queue time of the RESOURCE?
They’re set to “Use Resource Group Values”.
double fudge…
IDK
create a sample/example …
i would try adjusting the values at resource level - and not the same as the group -
just to see if you can get some change.
also (i agree with bandersen) try looking at the job scheduling board to get an idea if the system is “seeing” the M/Q/ time.
gottalova a meaty scheduling problem…
Finite horizon affects this - if the job is scheduled finitely, the queue times are not supposed to apply.
@hmwillett is Gil correct? did it resolve your issue?
if you confirmed it would be great to know - if you can
Sorry–juggling a lot.
We schedule infinitely, so I do not believe this is our issue.
Our finite horizon is 0.
Well, your experience matches mine, Hannah. The queue times do not work properly according to the documentation in that they are added when scheduling finitely. We don’t use move time here, so I can’t speak to that directly.
I will say that in addition to queue times, there are several other nuances with scheduling that do not work as advertised. We are in the middle of an upgrade from V8 to E10, and I am anxious to do some testing to validate exactly what the scheduler is doing.
just throwing this OUT there. - I’ve never tried it
but IF you really need to consider QUEUE time -
maybe you can simulate Queue Time with an preceding operation
either at the same resource group - or a phantom group
i haven’t thought it through all the way - just wondering out loud
it is Friday afternoon 
on the first full week back to work …
It could work, but it may depend on how your company transacts or completes operations. It could be a huge pain with unfinished operations. I could see it working though if you really needed it.
2 Likes
You are correct Al, the system, at least on 10.2.700 is not honoring the ‘use resource group values’ box.
I know this used to work, we modeled it extensively at implementation years ago. But now here I am resurrecting yet another dead thread.
To the other point yes you need a padding operation to use Queue time. We call that operation ‘START’ and I think it’s a good idea to have it anyway. Because our documentation control department reviews and releases all jobs that scheduling wants built. This requires a labor transaction to ‘get the job going’ with partwip records being created and the job aging counter begins. Our second op is a kitting operation and nobody wanted to figure out how long it’s supposed to take to pick a job, just 16 hours of queue time should do it.