Order Book

Order Book is an application designed to streamline the management of your Orders. This is made easier by providing Locations, TransportRequests, Companies and Conditionals. All these entities can be managed through our APIs, enabling you to constantly enrich Orders and capture domain knowledge that is not available in the source systems.

Philosophy

Keep the input simple

Source of orders

All of our customers have a source of work, which is translated into orders on our side. We provide software to make a great planning with these orders.

Basic requirements

The planning needs some fundamental information that can always be found:

• when : Time windows for pickup/delivery
• where : Locations for operations

API design philosophy

We typically try to offer APIs that do not require in-depth information about the settings that control and steer the planning. This approach:

• Keeps the complexity on the input side lower
• Allows for a faster integration
• Recognizes that not all planning-related options can be found in your source system (which is probably not a planning system)

Keep the source of truth clear

Order modification approach

Since orders come in from another source (the leading system), we don't offer direct changes or updates at the order level in orderbook. This prevents confusion about where data was changed.

Using conditionals for modifications

Some data needs to be modified structurally for planning purposes. For this, we offer the concept of a conditional:

• Applied to any order that matches its conditions
• Has a fixed effect on matched orders
• Makes modifications visible and traceable

Benefits of conditionals

We try to make this process as visible as possible and use conditionals to capture what is:

• Hard to capture in the source system
• Has a clear impact on the quality of the planning

For more information, look at the concept of the conditional within the orderbook domain.

How to organise orders for use in the planning

The deprecated category feature

Originally, we started by having categories within the API but quickly found them to be unsuited for all use cases as you can have only one category per order. This feature has been deprecated in favor of Labels.

Labels

Basic functionality

An order can have many labels, which on their own only serve an informational purpose.

Integration with other platform tools

There are other tools within our platform that hook into the presence of labels to apply rules, such as:

• order vehicle constraints that allow you to apply a penalty or incentive
• Matching labels on orders with labels on vehicles

Using labels for planning selection

Another use of the label feature is to select which orders belong together in a planning:

• The filter works by matching any label it can find on your order
• For more specific control, add concatenated versions of labels

Example:

• If you have labels depot-antwerp and frozen in a filter, any frozen good would be included
• A concatenated version like frozen-depot-antwerp becomes specific to only select frozen goods from that depot

Plangroup

Orders can have one plangroup. This is a feature to make a harder separation between sets of orders when they are, for example, from separate business units. In the filter, you can select one plangroup, and within that plangroup, you can still use labels to subselect the orders.