Table of Contents

Order Allocation

Colin Updated by Colin

Orders are automatically allocated to available inventory immediately upon being submitted. When you have inventory in multiple warehouses, ShipStream provides a very flexible system for automatically allocating each order to the optimal warehouse according to your preferences. These options for controlling the allocation exist both in the configuration which can be set at the Global and Merchant scope, and also on an individual order basis using the Order Priority and Allocation Options fields described below.

The order allocation process occurs automatically as long as the order is Ready to Ship, and will take into account the real-time multi-warehouse inventory availability, Packing Solutions and Rate Shopping as appropriate.

The order allocation process is also affected by the following factors:

  • The Order Priority value of all orders in the system
  • The relative submission timestamps of all orders in the system (first come, first serve)
  • The Allowed Warehouses configuration of each merchant
  • The allowed_stock_ids value of the order's Allocation Options if specified
  • The Order Allocation Algorithm configuration of each merchant
  • The Dynamic Allocation option configuration of each merchant

All of these are described in greater detail below.

Order Priority

Orders are allocated to available inventory in real-time based on the Order Priority and the submission date and time (first-come, first-serve). Manipulating the Order Priority of individual orders allows you to override the chronological sorting to cause it to be higher priority (lower numbers) or lower priority (higher numbers). You may assign any number in the range of 0 (first to allocate) to 100 (last to allocate). The default priority is 50.

An order placed on hold will still maintain the inventory allocation preventing other orders from consuming that inventory while it is on hold.

Stated differently, all orders which have the same Order Priority will be allocated based on the submission date and time, but orders with different Order Priority will come before (lower numbers) or after (higher numbers) accordingly. Here are some examples:

  • Orders submitted at a later date but given a higher priority (e.g. 25) would be allocated before older orders with the default priority (50).
  • Orders with a lower priority (e.g. 75) will be allocated only after all other orders with higher priority (any number lower than 75).
Changing the Order Priority of an existing order can cause other orders/shipments which are not already processing (picking) to be immediately deallocated (backordered) so that the higher priority orders can be allocated first, or cause the updated order to be deallocated if other orders should be allocated first based on the new Order Priority value. Similarly, submitting a new order with a higher priority than existing orders can cause some existing orders to go from New to Backordered if there is not enough inventory to cover both the new order and the old orders.

The Order Priority can be set by both Admin Users and Client Users and can be set on the Order page or using a mass action on the Orders grid.

Order Priority does not directly affect the order in which shipments are batched. Batching and Bulk Fulfill Orders only look at Shipments of orders that are Ready to Ship (not backordered and not on hold), which affects the Target Ship Date of the shipment. To prioritize the batching of one set of shipments over another with the same Target Ship Date please see Picking Classes.

Allowed Warehouses

In the System > Configuration > General > Warehouses > General configuration section there are three fields which can be configured at the Merchant scope (see Configuration Scopes) to control how merchants can view and use your warehouses.

The Allowed Warehouses configuration will determine which warehouses a merchant can see and use. This will affect all aspects of the system as you may expect. The disallowed warehouses will be hidden from the UI, API requests referencing the disallowed warehouse will be rejected.

If a merchant has inventory in a warehouse that is not in the Allowed Warehouses list, the warehouse and inventory will still remain visible in places where it would otherwise not be to avoid losing visibilty of that inventory. In some cases the disallowed warehouse name may still appear or may appear as "hidden".

The Allowed for Fulfillment option may be configured independently by choosing a subset of the Allowed Warehouses to determine which warehouses an order may be assigned and allocated to. This can be useful when you want to bring up a new warehouse or take down an old warehouse in stages. For example, by not allowing "Reno, NV" for fulfillment one could create an ASN at the new warehouse and start receiving inventory, but block orders from being allocated there until it is ready to start fulfilling orders.

Order Allocation Algorithm

You can choose a Primary and Secondary Allocation Algorithm in the System > Configuration > General > Warehouses > Order Allocation configuration section.

In the case where the Primary option fails, the Secondary will be attempted. If the Secondary fails too, the Default Warehouse option will be used.

If an algorithm fails to produce a result, a note will be added to the order history explaining why. Common reasons would be that not enough data was present to make a determination, or that the variables to determine the outcome were equal for all warehouses.

The order allocation algorithms currently offered by ShipStream are as follows. The codes provided may be used when overriding the allocation options at the order level.

Shortest Distance

This utilizes a large database of cities, towns and postcodes to determine the "rough" geographic location of your warehouses and the destination address and prioritizes the warehouses according to which is closest. This does not use rooftop or street-level accuracy as that precision is simply not needed to arrive at an optimal result.

Code: geographic-distance

Cheapest Total Cost

This uses your rating data to estimate shipping costs based on the order's contents and rate shopping results and chooses the cheapest warehouse to ship from accordingly.

Code: cheapest

Fastest Transit Time

This uses the Days In Transit tables from the rating data to estimate delivery dates based on the order's shipping method and chooses the fastest warehouse to ship from.

Code: fastest

This algorithm may or may not provide better results than the Shortest Distance algorithm, but requires considerable setup and maintenance so is generally less recommended than Shortest Distance.

Least Packages

This chooses the warehouse allocation that would result in the least amount of packages being sent. If there is a tie for first then it will fall back to the next algorithm.

Code: leastpackages

Default Warehouse

This will simply allocate as much to the Default Warehouse as possible and then the remaining items to the other warehouses in the order that the warehouses were created.

Code: default

The order of warehouses may be overridden by setting the allowed_stock_ids property as described below. This can be useful if all you want is a strict prioritization based on your arbitrary sort order.

Specific Locked

With this algorithm, all order items will be locked to a specific warehouse regardless of availability or any other criteria. This algorithm may only be specified for individual orders (see the Individual Order Override section below) and requires that only one warehouse is specified.

Code: specific-locked

Using the "Lock to Warehouse" and "Unlock from Warehouse" mass actions on the order grid works by applying this algorithm to each order with your chosen warehouse.

Single Warehouse Option

Choosing "Yes" for this option will prevent an order from being split between multiple warehouses. If all of the order items cannot be fulfilled from a single warehouse, the order will be placed on backorder.

Using either Specific Locked or Single Warehouse can cause an order to be backordered even when there is inventory "available" if the order is not available in the correct warehouse.

Static vs Dynamic Allocation

When using "Shortest Distance", "Cheapest Total Cost" or "Fastest Transit Time" allocation algorithms, ShipStream performs real-time Dynamic Allocation for merchants that have inventory in multiple warehouses. This takes into account which warehouses have inventory in stock to get the order completed as soon as possible using available inventory. However, if you'd rather your orders be allocated to the optimal warehouse ignoring real-time inventory, you can disable Dynamic Allocation. The order would then remain backordered until it is in-stock at the optimal warehouse. This is also referred to as Static Allocation since the allocation does not change as inventory changes — it will remain static regardless of available inventory.

By System > Configuration

This configuration is located at System > Configuration > Catalog > Inventory > Product Inventory Options.

By Product

You can also override the configured default at the Product level so that specific products can be treated differently from the default:

By Order

And of course at the Order level as well, using the UI, scripts, or the API:

Individual Order Override

The configuration determines the default behavior used for all orders, but in some cases, you may wish to override the default behavior for individual orders. An order field called allocation_options is available for this purpose. It is plain text using valid JSON format and may be set via the UI, the API, or via a Before Create Order (BCO) Script.

The format of the JSON object may contain three keys:

  • algorithms - An array of the allocation algorithms that may be used for this order.
  • allowed_stock_ids - An array of warehouse ids that may be used for this order.
  • single_warehouse - A boolean indicating if the entire order may or may not be split among multiple warehouses. (true - allocate to only a single warehouse - do not split)
  • dynamic_allocation - A boolean indicating if dynamic allocation is overridden for this order (true - use dynamic allocation, false - use static allocation).

For example, to lock an order to a specific warehouse one could choose the specific-locked algorithm and specify the id of the warehouse you want to use:

"algorithms": ["specific-locked"],
"allowed_stock_ids": [2]

The codes for the allocation algorithms are as follows:

  • Shortest Distance - geographic-distance
  • Cheapest Total Cost - cheapest
  • Fastest Transit Time - fastest
  • Least Packages - leastpackages
  • Default Warehouse - default
  • Specific Locked - specific-locked

The warehouse IDs can be obtained through the System > Enumerations page, the API using the warehouse.list API method or from the System > Warehouses page.

How did we do?

Order Processing Loop