fulfillmenttools
API documentationIncident ManagementFeedback
Products
Products
  • Products
  • Core
    • Fulfillmenttools and it's surrounding system
    • Facilities
      • Managed facilities
      • Supplier facilities
      • Facility groups
      • Facility discounts
    • User management
    • GDPR
    • External actions
    • Notification center
    • Incident management
    • Tags
    • Stickers
    • Articles
  • Inventory Management
    • Overview inventory modules
    • Listing
    • Article categories
    • Stock
      • Stock availability
      • Stock properties
      • Stock updates
    • Reservations
    • Inbound process
    • Storage location
    • Zone
    • Inventory traits
    • Channel inventory
    • Measurement units
    • Stow jobs
    • External stock change reasons
    • Configurations
  • Availability & Promising
    • Availability & promising in customer journey
      • Earliest possible delivery date
      • Availability in delivery time period
      • Availability for specific delivery date
      • Checkout options
      • Delivery promise
    • Latest picking start
  • Distributed Order Management
    • Order management
    • Order routing
      • Fences
      • Ratings
      • Order split
      • Routing strategy
      • Item bundles
      • Re-route
      • Decision logs
      • Unroutable orders
      • Pre- and backorders
      • DOMS toolkit
  • Order fulfillment
    • Picking
    • Packing
    • Handover
    • Custom services
    • External documents
    • Load units
    • Interfacility transfer
    • Pick job target time
    • Configurations
      • Picking configuration
      • Packing configuration
      • Handover configuration
      • Printing & document configuration
      • Parcel tag configuration
  • Carrier management
    • Carriers and connection to facilities
    • Carrier country service mapping
    • Same day delivery
    • Custom carrier
    • Available carriers
  • Returns Management
    • Introduction to returns
    • Return reasons
  • Use Cases
    • Creating & executing stow jobs
    • Creating orders with interfacility transfers
    • Demand-driven replenishment
    • Expected stock in availability
    • Incoming goods & storage
    • Multi order picking
Powered by GitBook
On this page
  • Introduction
  • Functionality of the routing strategy
  • Basic configuration
  • Nodes and the principle of inheritance
Edit on GitHub
  1. Distributed Order Management
  2. Order routing

Routing strategy

PreviousOrder splitNextItem bundles

Last updated 2 months ago

Introduction

The routing configuration can be adapted to different levels of complexity based on individual requirements.

In more homogeneous setups — where the logistics network, product portfolio, and sales markets are relatively uniform — a largely standardized routing strategy is often sufficient. In this simpler variant, all orders follow the same routing rules regarding , , and . This means, for example, that an order split can either be allowed or restricted for all orders.

Additionally, settings related to the possible consecutive routing decision also apply uniformly to all orders. For example, can be either allowed or restricted for all orders without distinction.

In more complex setups, the 'routing strategy' concept enables differentiation across multiple context-specific routing configurations within the same tenant. In regards to the example above, this means that order splits can, for example, be allowed for orders from the sales channel 'Webshop' while being restricted for orders from the sales channel 'Amazon'.

This also includes distinctions in consecutive routing actions. For instance, manual rerouting could be permitted for orders from the company’s own web shop while being restricted for marketplace orders.

This level of configurability ensures greater flexibility in handling diverse order sources and business requirements.

Functionality of the routing strategy

Basic configuration

The basic configuration serves as the foundation of the routing strategy, defining all essential routing settings such as fences, ratings, order split behaviour, and rerouting rules. The basic configuration cannot be deactivated or deleted. All settings defined within the basic configuration are inherited by subsequent nodes but can be overridden or extended at the node level if needed.

For simple and homogeneous setups, the basic configuration is usually sufficient to cover all necessary use cases without requiring additional nodes.

Nodes and the principle of inheritance

Introduction

For more complex setups, any number of nodes can be added on top of the basic configuration. Each node defines specific conditions that determine which orders or requests it applies to, along with the ability to override or extend routing rules inherited from the basic configuration or previous nodes.

The conditions within a node can reference any property/attribute of an order or request. When these conditions are met, the system first evaluates whether a subsequent node’s conditions also apply. If so, the process continues with that node. If no additional nodes match, the last positively evaluated node serves as the final aggregation point for the routing configuration. Starting from the basic configuration, all applicable nodes contribute their respective rules based on the described inheritance principle, forming the final rule set that determines how the order or request is routed.

As a fundamental rule, all settings from a previous node are inherited by the next one, ensuring a structured and flexible approach to the routing configuration.

Activating, deactivating, and deleting nodes

Each node, except for the basic configuration, can be individually activated or deactivated. If a node is in an inactive state, it is skipped during the evaluation of the routing strategy, and its routing configurations are not considered.

Activating or deactivating a node also has implicit effects on any subsequent nodes that are directly linked to it.

Example: If the "Amazon" node is deactivated, the "PRIME" node, which is dependent on it, is automatically set to inactive as well.

In addition to activation and deactivation, nodes can also be deleted. There are two ways to do this:

  • Deleting a single node: In this case, subsequent nodes shift up to maintain continuity in the routing structure.

  • Deleting an entire branch: This removes the selected node along with all directly or indirectly connected nodes, effectively eliminating the entire path originating from that node.

Scheduled Activation and Deactivation

In addition to manual activation/deactivation, a timeframe can be configured to automatically activate or deactivate a specific node (and any dependent nodes) at a predefined time. This feature allows for dynamic adjustments to routing strategies based on operational needs.

For example, a specific routing configuration can be set up to handle increased order volumes during peak periods. Once the defined timeframe expires, the node is automatically deactivated, reverting to the default routing setup without requiring manual intervention.

fences
ratings
order splits
manual rerouting
Routing configuration for homogenous setups
Complex routing config with context based differentiations
Nodes and the principle of inheritance