Table of Contents


Colin Updated by Colin

When an order item cannot or will not be fulfilled with the current inventory, the item is said to be Backordered.

ShipStream supports the concept of backorders at both the order level and the order item level. Thus, it is possible for one or more items to be backordered while one or more other items are not backordered.

The order status can then be either Backordered or Partially Backordered. To understand the difference you must understand the Ready to Ship status and the Backorder Policy. A Partially Backordered order is one that has backordered items and non-backordered items and is not prevented from being shipped in its current state while a Backordered order is one that has at least one backordered item and cannot ship in its current state.

Allow Backorders

ShipStream by default allows backorders. When Backorders are allowed the System will accept an order when there is not enough inventory in-stock to fulfill the entire order immediately. This behavior can be changed at both the Global and Merchant configuration scopes and also on a per-SKU basis. The Global and Merchant configuration can be set at System > Configuration > Catalog > Inventory > Product Inventory Options > Allow Backorders Default.

The configuration value will determine the behavior when the Product's "Backorders" attribute is set to "Use Config". You can override the configuration value for each SKU in the Inventory tab by choosing a value other than "Use Config" for a given product.

When Allow Backorders is set to "No", the System will reject the order when there is not enough inventory in-stock to fulfill the entire order immediately. The messages will refer to the products that are not available.

Ready to Ship

An order in ShipStream is Ready to Ship if it is not on Hold status and is not prevented from being at least partially fulfilled by the current inventory levels and the Backorder Policy. When an order transitions from "Ready to Ship: No" to "Ready to Ship: Yes" the Ready to Ship time is recorded and displayed on the order page. This timestamp tells you the moment that an order could be fulfilled from the warehouse operations point of view. This timestamp is also used to inform the determination of the Target Ship Date.

Backorder Policy

The Backorder Policy can be configured at the Global and Merchant scopes under System > Configuration > Sales > Backorders > Backorder Policy. This setting determines in a situation where an order is partially backordered if it will be considered partially fulfillable or not. If the order is fully in-stock then the Backorder Policy has no effect.

The Backorder Policy may be specified for individual orders and updated even after the order is created. If not specified, the configuration will be used as the default Backorder Policy.

The Backorder Policy options are:

All or Nothing

Do not ship anything until all items are in-stock.

As Available

Ship in-stock items as they become available. No limit to the number or frequency of additional shipments.

Up to X

This policy behaves initially the same as As Available, but effectively changes to All or Nothing before the Xth shipping "occasion" occurs. The "X" refers to the number of separate occasions upon which one or more shipments can be fulfilled. An "occasion" is based on when the Ready to Ship Time was last updated so is effectively counted once each time the order is partially fulfilled since this is updated each time new inventory is allocated to an order.

As inventory is adjusted, the order allocation and status will update automatically and when the Backorder Policy allows an order to be fulfilled based on the inventory availability and assuming it is not on hold, the Ready to Ship status and time will be updated.
Up to X Example

If you have an order for 5 items and only one item is in-stock and the Up to X value is 3, the one item in stock would ship right away and the remainder would be backordered. If another item came to be in-stock, then that item would also be ready to ship and the number of "occasions" counted would then be 2. The remaining 3 items of the order would then be backordered until all 3 units were in-stock to prevent a 3rd shipment from being shipped with items still backordered. Effectively, the system would prevent a fourth shipment for this order since 4 is greater than the Up to X value of 3.

Since this metric counts "occasions" rather than individual shipments or packages, it is possible that more than X shipments will be shipped if the order was split into multiple shipments on any occasion, such as is the case when the items don't fit in a single package or the inventory is split between multiple warehouses.

Assigned vs Allocated Inventory

An order for an item that is Backordered and not locked to a specific warehouse (see Order Allocation) will not be assigned to any warehouse meaning it could in the future be assigned to the next available warehouse. If the order is locked to a specific warehouse the inventory will be Assigned to that warehouse even though it is not Allocated indicating that it will only be fulfilled from that warehouse regardless of availability in other warehouses. Only when the inventory becomes available will the inventory be Allocated and deducted from the product's Available inventory. Order items that are Assigned but not Allocated are not included in the product's Allocated inventory.

Order not locked to a warehouse
Order locked to Newark, NJ

Why is the item Backordered while there are units Available?

When you lock orders to one warehouse or another it is possible that some items will be backordered because they are not available at the warehouse they were locked to. Additionally, if the effective Backorder Policy for some orders is All or Nothing, it is possible that the units that are available cannot be shipped because other items on those orders are "blocking" the order from being Ready to Ship. Therefore, you can have a situation where there is inventory in-stock but that cannot be shipped.

Additionally, an order item could have Dynamic Allocation turned off. This would require an item to be fulfilled from the closest warehouse regardless of inventory levels at other warehouses.

Possible solutions might be:

  1. Cancel the backordered items from some orders
  2. Change the Backorder Policy to allow the orders to be partially shipped
  3. Change the order priority higher or lower to allow other orders to take precedence
  4. Receive more inventory so that the backordered orders can be completed
  5. If caused by Dynamic Allocation being off:
    1. Is Dynamic Allocation off in the Merchant's configs, thus a conscious choice of the Merchant
    2. Is it off for just a particular Product: Should the product still have this setting turned off?
    3. Can this Particular Order ignore the Dynamic Allocation and set it to true.
ShipStream uses FIFO when allocating inventory to orders to ensure "fairness" and to avoid a situation where large orders are perpetually backordered because small orders with fewer backordered items jump in front. However, you can set/change an order's Priority to override this strict FIFO ordering and more finely manage the allocation of orders relative to one another.

How did we do?

Packing Solutions

Ready to Ship