Group Mode

If task grouping is enabled, the Visual Scheduler will work in group mode, i.e. all tasks that are within the same group will be taken into account for user actions. A task group is either based on the task group id, if the useTaskGroups preference is set, or on the customer name. A group action can be related to viewing the data, unplanning visits or planning tasks. When holding the Control key pressed, the grouping is temporarily disabled, allowing users to act on individuals tasks, regardless of their task group.

Windows

Selecting the menu option Windows->Show all windows will rebuild the layout of all available windows within the application's desktop. Note that the menu is only available when running the Visual Scheduler in a separate application window.

Search

By pressing Control-F in a data table of the Visual Scheduler, a search dialog opens for input of the search string. By clicking OK, the table will be scanned for the provided text. If an occurrence after the selected row and column is found, the table will focus on this cell. The search is performed case-insensitive. By pressing F3, the next occurrence of the text is searched. If the end of the table is reached, the search is continued on the first row and column of the table until the next occurence is found. The search string is private to the current table, i.e. the search text is not used within other tables when F3 is pressed.

Assigned Date/Time

When tasks have an onTheWay status and the assignedDateTime field is specified, a check on the plausibility of the start time needs to be performed. Otherwise, the task might be inserted into a wrong position if the task has been taken from another trip or a position in the trip other than the next planned task. Setting the scheduled date/time equal to the assigned date/time is not a solution to the following problem: A resource has decided to visit another call (in the current trip or in one of the following trips) instead of visiting the next customer as planned by the planner. Then, the planning has changed and the scheduled date/time needs to be adapted. Subsequently, recalculation of the trip will increase the scheduled date/time with the travel time. This works fine if the task remains at the same position in the trip. However, it fails if the task has to be removed from the former position and needs to be inserted into the current trip. Without setting the scheduled date/time, the task will not be removed from the former trip. It will remain in the former trip, causing inconsistencies. Therefore, the idea is to adjust the scheduled date/time to the assigned date/time. In that case, the visit object in the former trip is removed and the task is rebuilt and added to the current trip at the new position. However, when updating the trip after normalization, the scheduled date/time will be updated in the database and the refresh algorithm will again reset the scheduled date/time. Furthermore, if the current trip contains a planned task before the assigned task, the assigned task is inserted after the planned task causing the predecessor to remain before the timeline, which is incorrect. In fact, in this case, the assigned task should be inserted before the first planned but unassigned task (or at the end of the trip if not existent). Caution needs to be taken to distinguish tasks that are assigned but have not yet been closed and tasks that are already closed. In both cases, the assigned date/time is defined, but in the latter case, the actual date/time overrules the assigned date/time. Bottom line: the Scheduler inserts the assigned but unclosed task at the next possible position in the trip if it is not already there. The next possible position is before the first planned but unassigned task or at the end of the trip if there is no such task.