The supporting data are defined in the next section but identified here as a group to indicate the source (raw material) for the different Schedule tables (Schedule, Route, and Stop). Internal rules will be enforced so that the corresponding supporting data (raw material) is available. The supporting data provides the link back to the corresponding orders, resources, drivers, and customers.
It is possible to override the settings on the different Schedule tables once they have been created. You might want to override settings to fine-tune the way the Schedule is built. Additional functionality to manage the Schedule data will be available through the different Descartes Route Planner applications.
Figure 3: Supporting Data
The supporting data breaks down into the following data structure:
Activity (Orders) - The data representing the order view or a specific shipment leg view that needs to be Scheduled. An activity represents one leg of the order that has a specific geographic location and point in time. As we build out this data model we will see that an external order can have more than one target activity. Typically, an order will have an origin and destination activity, but that doesn’t mean that we will always have two activities for each order. We can have one, two, or more. The activity table bridges the gap between external order information and internal scheduling settings. Both external and internal data are combined on each activity record. This is important because the existing customer order records do not need to be cluttered with additional scheduling-specific data details.
· Activity records are created whenever an order comes into Descartes Route Planner. An order can be populated via an API, a Business Document, a third party order entry system, or a Descartes Route Planner order management system. Typically all Descartes Route Planner orders will be populated via Business Documents or the Descartes Route Planner Transport Order Entry module.
· All order line items can be consolidated into one activity record.
· Additional scheduling attributes can be introduced at the activity level.
· One Activity can be related to another Activity through the same order key relationship.
· This relationship would typically be used to relate a pick-up with a drop-off leg of a double-ended type order.
· In the future, this relationship can be used to model order splitting where different order lines can be split across different activities.
· Separating the activity from the order allows us to potentially support:
¡ Blanket orders
¡ Consignment orders
¡ Multi-task orders
Resource - The data that represents a consolidated physical view of the thing (Resource) that actually performs the work. Typically, this would include the physical vehicle, driver, some time restrictions, and scheduling attributes. This is a little different from the previous resource representations, particularly with respect to the date aspect. The new resource can be used as the default state of a Route that will be associated with it.
Ü Note - The resource can only be linked to a Schedule through a Route record.
· The resource records can be populated via an API, Business Documents, a third party resource management systems, generated via Route Templates (using the Descartes Route Planner UI).
· When a resource is created and a Route Template specified, many of the scheduling attributes will be initialized to the Route template values.
Schedule Template - A table where different Schedule templates with different scheduling attributes can be created. Once created and referenced, new Schedules can be created based on the Schedule template settings. Many of the Schedule attributes can be predefined, minimizing the effort needed to create Schedules from scratch. For the most part, the Schedule and Schedule Template attributes are the same and used as defaults during the Schedule creation process.
