Shift feature should allow to define opening and closing periods

[Robin-C]

Right now, when trying to go from erlangc to shifts, the engine will sometimes "shift" a ressource even tho required_ressource was set to 0 at this period.

Practically, what it does is it will shift someone to work at 3am even tho there is no required_ressource needed before 6am.

It happens because:

1) There is a valid shift defined to cover this period 2) The engine is trying to optimize for shift coverage and will shift someone earlier than needed because it prefers a larger coverage rather than useless overlap with additional ressources later.

Describe the solution you'd like I'd like to be able to pass an optional dictionary with the day and its opening and closing periods where no shift can take place outside.

Alternatively, today I'm dynamically providing the acceptable shifts to the optimizer and run it as many times as I have days.

[rodrigo-arenas]

Hi, in this case, as you mention, as long as there is a valid shift that covers 3 a.m, it might end up shifting someone at that time, so it will also cover the demand of the beginning of the morning shift

There are several ways you can try to improve this:

• Modify the definition of the shift depending on the required_resources parameters, this is, if required_resources at position i is 0, then all the shifts at position i gets set to 0 as well
• If you are using MinRequiredResources, you can try to set a "cost", this is a penalization on the objective function per shift with a dict like this cost_dict = {"Morning": 8, "Afternoon": 8, "Night": 16, "Mixed": 7} This will tell the optimizer that, for example, it is twice expensiver to shift someone at night than in the morning, so the optimal schedule might change to shift someone in the morning, even if the is no need for it the whole shift, but it's just cheaper
• Try to smooth the results of ErlangC, if for example a morning shift starts with a requirement of 40 resources at 8 a.m and then it requires 8 resources from 9.am , then to not having so much different between scheduled and required... it makes more sense to the optimizer to schedule 32 (or so) resources at midnight so they end up the shift at this time in the morning.. try to make those changes between shifts smoother

I hope it helps

[Robin-C]

1 is not really feasable because some days, we might need someone at 6am and the next day at 7am.

I like solution 2 the most. I couldn't see mention of the cost parameter here. I'll try and report back :)

3 seems like as much work as adding a constraint in the source code

Thanks Rodrigo!