Skip to content
howiesommerfeld edited this page Mar 1, 2016 · 4 revisions

##Overview

The first step in integrating to the Trackmatic system is to define the various business cases which exists in your business system. Once these business cases have been defined we can use Trackmatic building blocks to represent these business cases inside the Trackmatic system.

When talking about logistics in general there are normally a set number of scenarios which can occur. Although the terminology can be different the underlying concepts are the same. The remainder of this section will layout the various scenarios and how they should be mapped to the Trackmatic Building Blocks.

The diagram above depicts the various action-scenarios which Trackmatic caters for. By traversing the tree downwards, each scenario can be specifically defined. Hence only the differentiating characteristics will be discussed in detail here.

##Outbound vs. Inbound

Outbound actions are those which can be allocated onto a Trackmatic route. This requires a vehicle leaving its headquarters in order to execute the action at hand. An example of this would typically be a delivery or an uplift of sorts.

Inbound actions are those which do not get allocated onto Trackmatic routes. They are reliant on a customer coming to the client in order to complete the action. These are typically action items which are marked as “Customer-to-collect”.

###Convertible Actions Any action has the potential to be convertible. This implies the ability for an Inbound action to be transformed into an Outbound action and vice versa. This may occur, for example, if a customer calls to say that instead of coming to collect the action as was originally planned, they would prefer instead for it to be delivered to them. On the other hand, if a delivery was scheduled to be delivered to a customer, but they call and request to pick the item up because they are in the area, this could be converted from an Outbound to an Inbound action.

##Deliveries and uplifts ###Direct Vs. Third Party

Outbound actions of either of these types fall into one of two categories, namely “Direct” or “Third-Party”. This property relates directly to the Entity of the action.

A “Direct” outbound action means that the action is being executed on behalf of the client itself. This differs to the case of “Third-Party” outbound actions, whereby the action is carried out by the client on behalf of a third party company or individual.

###Static vs Ad-hoc Each of these categories branches out into one of two more sub-categories. This would be either a “Static” or “Ad-hoc” action. The result of this property is directly related to the DECO associated with the action.

For “Static” actions, this implies that the DECO where the action is to be executed is permanently saved within the Trackmatic system. This typically applies to places where regular or recurring deliveries/collections are to take place.

Defining an action as “Ad-hoc”, implies that the DECO is treated as a temporary item within Trackmatic’s domain. Its geospatial information will be present on a route while it is active, however, upon completing the route, no further references are stored within Trackmatic to the DECO at hand. This is typically chosen when deliveries/collections are to be made to customers on a “once-off” basis.

Next > API Documentation

Clone this wiki locally