Scheduling of Committed Activities¶

Once a visit to an activity is at a status of committed (30) or greater, the DSE no longer chooses where to schedule the visit. Instead the visit is placed in the schedule according to a set of rules.

Travelling Status Onwards¶

Once a visit is at a status of travelling or greater the positioning of the visit is based on the actual times that events were recorded as happening. For these visits the status date (date_time_status) on the activity status record is always used to determine when a change actually happened.

Completed Activities¶

For completed activities (status 70) there should be multiple activity status records to record when the activity was started and finished and when the resource started travelling to the activity (if any travel was involved).

For example, if a resource started travelling to an activity at 11:30am, arrived at 12pm and finished the activity at 1pm, then there should be at least three separate activity status records to represent this. The first would be at status 50 (travelling) and have a status time of 11:30am, the second would be at status 60 (on site) and have a status time of 12pm, and the latest status would be status 70 (complete) and have a status time of 1pm. The DSE would then display the activity with the travel start, activity start and completion times set accordingly.

Note that for a completed activity the estimated duration provided in the input data is not used. Instead the activity start is always taken from the on-site status date, and the activity end from the complete status date. If there is no on-site status record then the activity will have zero duration and will not be visible in the Gantt display on the Workbench.

Likewise the travel start is always taken from the travel status date; if there is no travelling status record then no travel will be displayed to the activity.

Visit Complete Status¶

The 'visit complete' status (status 68) relates to split activities. See the scheduling concepts document on split activities for further information.

Pending Completion¶

The pending completion status (status 65) is used to signify that a resource will shortly be completing an activity. The scheduling engine will treat this status in the same way as an on-site status, but the Schedule Dispatch Service will not. See the section on the Schedule Dispatch Service for further details.

On Site¶

For an on-site activity (status 60) the travel start will come from the travelling status date (if there is one, otherwise no travel is displayed), and the activity start is taken from the on-site status date. The activity end is then estimated from the activity duration specified in the input data, taking account of any resource proficiencies.

Note that sometimes there may be multiple on-site statuses for an activity. For example the resource may need to update the expected duration of the activity after starting work on it. By default in this case the activity start is taken to be the status date from the first on-site status.

For example, suppose a resource starts work on an activity at 12pm, but at 12:15pm updates the activity to say that it is now expected to take 2 hours. There would then be two on site activity status records: the first with a status date of 12pm and a later one with a status date of 12:15pm. However the scheduling engine will use the first status date as the time the activity actually started.

If, for any reason, the status flow is interrupted (e.g. an on-site is received followed by a travelling and then by another on-site) then the latest on-site status will be used for the activity start. Recall that the ordering of activity status records for an activity is based on the date stamp (date_time_stamp) attribute.

Waiting at Site¶

The waiting at site status (status 55) is used to indicate that a resource has arrived at the activity location but is not yet able to start work on the activity. This could be because the activity requires more than one resource, or due to access issues.

Activities at this status are treated in the same way as activities at status travelling.

Travelling¶

For visits of status travelling the start of travel to the activity is taken from the status date (date_time_status) on the latest activity status. Normally the travel time is then estimated as usual and the activity start time will be when the travel is expected to finish. However there are a number of exceptions to this:

• If a GPS fix is sent for the travelling resource then the remaining travel will be estimated from the GPS fix location to the activity location.
• If real time travel is enabled then the travel estimate will be a real time travel estimate.
• If an expected arrival time is supplied on the activity status then the travel will be expected to end at this time.
• If the activity has a fixed start time (date_time_fixed) then it will be expected to start at this time. In this case if the resource is not expected to finish travelling to the activity before the fixed time a 'travel in jeopardy' exception will be raised.
• If the activity has an 'earliest start time' then the activity start will be pushed back to this time if necessary.
• If time constraints are applied (based on the setting of parameter 'CommittedActivitiesConstraintsOption') then the activity start may be pushed back to a valid time.

If multiple travelling status updates are sent for an activity then the same rules apply as for on-site activities. This includes the use of the parameter 'UseLatestUpdateForStatusTime'.

Fixed Time Activities¶

Activities that are fixed to resource and to a date and time are scheduled at the fixed time. These activities are treated the same, regardless of their status, until they reach a minimum of travelling status (status 50).

Fixed Time Activities Outside of Shift Time¶

For activities that are fixed to a time before the start of a shift, but that end within the shift (including snap time), the activity will be assumed to belong to the upcoming shift, and the resource will be expected to travel from the fixed activity location to the first activity in the shift. Note that the DSE will still only schedule activities from the shift start time, and any travel will only start from the earliest travel start time for the shift.

For activities that are fixed to a time shortly after the end of a shift (and do not extend into a subsequent shift), the parameter 'FixedActivityAfterShiftBuffer' will apply. If the start time is within this buffer period (default 1 hour), then the activity will be assumed to belong to the previous shift, and the resource will be expected to travel to the activity will be from the final activity in the shift. Note that the DSE will still only schedule activities if they can be completed before the shift end time, and if the subsequent travel can be completed before the latest travel end for the shift.

For activities that are completely outside of any shift (including the allowed buffer time described above), the activity will be scheduled at the fixed time with travel to and from the resource home location.

GPS Fixes¶

When a GPS fix is received for a resource, this will have the following impact depending on the current state of the resource:

• If the resource is travelling then the expected remaining travel time will be updated based on the GPS fix location.
• If the resource is on site then the GPS will have no effect since the resource will still be expected to be at the on site location at the end of the activity.
• If the resource is on shift, but not currently travelling or on site, then the GPS fix will be used as the start location for the next travel for the resource.
• If the resource is not yet on shift, but the GPS is within the snap time for the shift, then the GPS fix will be taken as the start location for the first travel for the shift.
• If the GPS fix is outside of any shift time including snap time, then the GPS fix will have no effect.

Expected Arrival Time¶

An expected arrival time can be set against an activity. This is primarily intended for use with travelling status activities. In this case the DSE will take the expected arrival time as the expected time that the travel to the activity will end, and this will override the calculated travel end time. The activity will also be expected to start at this time unless other restrictions apply, such as availability constraints.

An expected arrival time can also be set on committed activities (status committed, sent, downloaded or accepted). However, setting an earliest arrival time is not recommended for activities at this status, and it is suggested to use other options such as an earliest start time or a fixed time instead. In this case the travel end will be constrained to be no earlier than the expected arrival time, but will not be shortened as a result of the expected arrival time. The estimated travel end will be the later of the expected arrival time and the calculated travel end time.

The expected arrival time is set in the input data using the expected_arrival_time field on the Activity_Status. This can also be set via the manual changes panel in the Scheduling Workbench.

Committed Status to Accepted Status¶

Activities at status committed through to accepted are scheduled according to a set of rules. These rules determine the order that they should be scheduled in and where in the schedule they appear. There are a number of parameters that control how the rules are applied.

Precedence Order¶

If there are multiple activities committed to the same resource (i.e. at a status of between committed and accepted), then the order in which the activities are scheduled is determined as follows:

1. Status: By default activities are first ordered by their status, so any accepted activities will be scheduled before downloaded activities, downloaded before sent and sent before committed.
2. Commit Sort Value: For activities at the same status the ordering is determined by the respective commit sort values on the latest activities status of the activities. The activity with the lowest commit sort value will be scheduled first. An activity without a commit sort value will be scheduled after those that do have a commit sort value.
3. Status Date: For activities at the same status and with the same commit sort value, the status date (date_time_status) will be used to determine the ordering of the activities. Activities with an earlier status date will be scheduled first.

The Active Shift¶

By default committed activities are always scheduled into the active shift for the activity.

The active shift for an activity is based on the 'earliest start time' of the activity, which by default is the current schedule time. However it is possible to specify an earliest start time on the activity status record (date_time_earliest), and if this is specified then the earliest start will be the later of this time and the schedule start. In addition, if any activity has an earliest start time then this will be the minimum earliest start time for any later committed activities for the resource.

The active shift is then the first shift for the committed resource to end after the earliest start time (i.e. the overlapping shift, if there is one, or if not the first shift to start after the earliest start time).

A committed activity will then be scheduled in the active shift associated with it. If necessary the activity will be scheduled so that it goes beyond the end of the shift (e.g. if there is not enough time remaining in the shift to complete the activity), but it will not be moved to a later shift.

Positioning Committed Activities¶

The positioning of a committed activity will be according to the following rules:

• It must be after any activities committed to the resource with status travelling or greater.
• It must be after any other activities committed to the resource with higher precedence, except those with a fixed date and time.
• It must not overlap any activities with a fixed date and time.
• If time constraints are enforced then if possible these will be obeyed. See the note below for further details.
• If no valid position can be found for the activity then it will still be scheduled in the last possible position in the shift, without any attempt to obey time constraints.

Example¶

As an example, suppose a resource has a shift from 9am - 5pm, which is empty apart from a private activity from 12pm - 1pm.

Suppose now that activity A is committed to the resource. The status is 30 and the commit sort value is set to 1. The activity has a duration of 1 hour and the resource needs to travel for 30 minutes to reach the activity.

The activity will be scheduled with the resource starting to travel at the start of his shift (9am) and starting the activity 30 minutes later at 9:30am. It will be completed at 10:30am and the resource will travel home.

Now suppose that the activity has an availability constraint which means it cannot be started until 10am. If we change the parameter 'CommittedActivitiesConstraintsOption' so that time constraints are applied, then the activity will now be expected to start at 10am.

Next suppose that activity B is also committed to the resource. This also has a status of 30 and a 1 hour duration, and the commit sort value is 2. The activity is 15 minutes travel from activity A.

The earliest this activity could be done is 11:15am, but it would then be expected to finish at 12:15pm, during the private appointment. As a result it is instead scheduled to be done after the private appointment.

Finally, suppose that activity C is also committed. This also has a status of 30 and has a 3 hour duration. The commit sort value is set to 1.5, which means that this activity is scheduled between activities A and B.

Note that the final activity is now due to finish after the end of the shift. This would now be invalid for schedulable activities, but since the activity is committed it is still scheduled here.

Note also that the current time has moved on to 9:45am. Since the first activity is still at status committed it is now being pushed with the timeline, so is now due to start at 10:15am.

Shift Cut Off¶

A shift cut off can be defined for a shift, via either the Shift, Resource or Resource_Type tables. Once the current schedule time has passed a shift's cut off time, only activities of committed status or above may be scheduled in the shift. This provides a way to define a time by which the shift's scheduled activities must be finalised.

The shift cut is a time span that is added to the start of the shift. Note that it can be defined to be negative so that the cut off occurs before the start of the shift.

A scheduling exception will be raised to indicate that the shift cut off is approaching for shifts that still contain uncommitted activities. The activation setting for the exception can be used to define how long before the shift cut off time the exception will be raised.

For example, if a shift starts at 09:00 with a cut off of 3 hours, the current time is 11:45 and the activation setting for the exception is set to 30 minutes. The shift contains both committed and uncommitted activities. The exception will have been raised to indicate that the shift cut off is nearing and the uncommitted activities should be committed soon. If they are not committed and the current schedule time passes 12:00, then the uncommitted activities will be removed from this shift to be scheduled at a later time. The DSE will no longer schedule any more activities into this shift unless they are committed or fixed to the resource and time.

Invalid Committed Routes¶

Sometimes it will not be possible to schedule the committed activities in a route validly. This could happen for a number of reasons, for example:

• The activity has restricted availability, and cannot be scheduled within its available period.
• Two co-requisite activities cannot be scheduled at the same time due to other constraints.

When this happens, the DSE will still always schedule the committed activities, even though this means that constraints will need to be broken. In this case, the DSE will simply schedule the activities in the active shift, ignoring any constraints. To alert the user to this, the DSE will also output exceptions as follows:

1. For the committed activity which cannot be scheduled validly, we raise an 'Externally Violated Constraints' scheduling exception with details about the Resource, Activity and Reason.
2. We raise an 'Invalid Committed Route' scheduling exception for the first invalid route of each resource which contains an invalid committed activity.

Recommendations¶

To achieve the maximum benefit from using the system it is recommended that the number of committed activities is kept to the minimum necessary. This allows the scheduling engine to respond dynamically to any changes affecting the schedule.

In addition, status changes should be fed to the system in near real-time, including travelling, on site and complete statuses for all activities. If GPS updates are available these can also help the system to respond quickly to any delays.

While there may be business reasons for committing multiple activities to a resource in advance, the system will be most responsive if each resource is sent activities one at a time, so they are only told about the activity that they are currently working on. The pending completion status can be used to ensure a new activity is sent when the current one is close to completion.

The next section details the use of the schedule dispatch service to suggest when activities should be committed to a resource.