Splitting

If the ERP sends tasks that exceed the total number of working hours for one day, OMD can break the load down to several smaller tasks with an equivalent total of estimated duration. This feature is called autoSplit and is executed during insertion of a task or when the estimated duration of an existing task is increased above a relevant level.

Optionally, the original task may require additional resources, as specified in the field resourcesRequired. In this case the resulting tasks can be grouped per resource and crew.

The autoSplit feature must be configured along with some other preferences, which are described below. Tasks that already come scheduled for an appointment are distributed over the following days. Tasks that are related to one autoSplit action can be identified by the alternativeId attribute of the tasks.

On insertion of task attachments for the original or any other related task, every task attachment is copied to all other related tasks. An update on a specific task attachment is not replicated to its copies.

When the autoSplit feature is turned on, any task exceeding the maximum working time (as specified in estimatedDuration) will be split into smaller tasks. The number of minutes is specified by the preference splitMaxMinutes. This preference must be a value greater than 0.

If the rest of the remaining work on the last day is below a reasonable limit, it might make more sense to add this load to the day before. The number of acceptable minutes on the last day can be specified by the preference splitWithhold.

Since splitWithhold is checked with precedence over splitThreshold, the resulting working hours can exceed splitThreshold.

When a large task is split, an optional threshold can be defined by splitThreshold. It defines the number of minutes of the maximum working hours, plus additional overtime that must be exceeded before splitting is executed. This preference is used to avoid splitting a task that can still be executed within a day (with overtime). A value lower than defined in splitMaxMinutes will have no effect.

The externalId of a task can contain delimiters that mark the end of a name, e.g. "ID0001.0", where the dot (".") marks the end of the ID's name base "ID0001". The splitting feature uses the name base to prepend to the externalId of new split tasks.

The splitting feature can split large tasks if the resourcesRequired value is larger than 1 (a.k.a "crew"). To create new externalIds, the above-mentioned base name of the original task is extracted and new IDs are created by sequential numbers. The numbers are separated by a delimiter defined in the preference splitDelimiterCrew, e.g. "ID001-2/3", where the slash ("/") is the delimiter and 3 is the number of the crewmember.

The splitting feature can split large tasks because of a estimatedDuration larger than the maximum working time in splitMaxMinutes.To create new externalIds, the above-mentioned base name of the original task is extracted and new IDs are created by sequential numbers. The numbers are separated by a delimiter defined in the preference splitDelimiterTime, e.g. "ID001-2/3", where the dash ("-") is the delimiter and 2 is the number of the day.

If split tasks are processed by a mobile worker, she sends attachments for every event related to this task, i.e. "onTheWay", "onSite", "closed" events. With the preference remapSplitTaskEvents all events can be remapped to the next upcoming segment of the split task, so that the segments are processed one after the other.

The event is remapped to the first segment that suits the required status-transition. Previous non-matching and unclosed segments of the split task remain untouched, hence the mobile worker must process them before. For example, if one segment is already "onSite", another "onSite" event will be applied on the next suitable segment, without closing or cancelling the first "onSite" segment implicitly.

All unclosed task segments are canceled at once if a cancel-attachment arrives at the server. However a sequence of one close- and one cancel-attachment is allowed to close a split task prematurely.

This feature requires the alternativeId to be equal throughout all related task segments.

Replicate tasks (tasks under control of another system) are allowed to change their estimated duration. To enable updates of all resulting split tasks, switch on the preference autoSplitUpdateReplicate. This requires the preference autoSplit to be switched on as well. For best results it is recommended to update the earliest and latest fields according to the duration.

ERP systems may send a canceled attachment after closing part of a splitted task, requesting OMD to cancel the remaining related tasks. This may cause a business tier exception if the canceled task if there are no remaining related tasks. To switched the exception off, set the preference warnOnClosedTaskUpdate to false.