Buy online, ship from store: Order flow for ‘Direct, then confirm’ warehouses

Last updated October 31st at 9:23am

About this article

This article details the process of a ‘Direct, then confirm’ order flow. ‘Direct, then confirm’ warehouses can be connected to a Brick and mortar, representing a physical store. Upon order placement, allocations are happening directly to the store. However, since store stock is harder to track, these stock quantities are considered unreliable in Centra, and require an allocation confirmation. A Point of Sales (PoS) system is needed to perform such confirmation. Staff members can also use the PoS to reject the allocation, if the order cannot be fulfilled from the store. A time out restriction can also be used, allowing for a conditional order fulfillment process.

Both stores and regular warehouses can be taken into account when fulfilling orders. Regular warehouses are not mandatory to use in this flow, meaning that store stock can be used fully and sold out, which is one of the main benefits of this flow. This also enables you to ship only from stores for certain countries where your main warehouses are not used. Additionally, orders can be fulfilled entirely or partially from ‘Direct, then confirm’ or regular warehouses. However, the main aim is to keep the order intact, ensuring it is delivered from one warehouse/store when possible.

So, imagine! With this feature, you’ll no longer have:

• split shipments when entire order can be shipped from store
• remaining pieces from old collections sitting on the shelves in stores
• “sold out” items on the website when warehouse is out of stock, but there are items left in stores

Read more about configuring the ‘Direct, then confirm’ Allocation policy setting here.

General overview

The ‘Direct, then confirm’ order flow can be used through the regular Allocation rules setup in your Centra. In this flow, the allocation happens towards the ‘Direct, then confirm’ warehouse and a request is done. The warehouse can then confirm or reject the allocation, and there’s also the possibility to set a time out. Let’s explore these below:

• If the warehouse confirms the allocation, the regular order flow commences and the order is fulfilled from the ‘Direct, then confirm’ warehouse. This means that a shipment can be created and delivered to the end customer
• If the warehouse rejects the allocation, then depending on the Allocation rule setup and the warehouses used, the order could potentially be allocated to another warehouse and processed further. Otherwise, the order is set as a backorder, requiring manual handling
• If a time out is reached, the allocation moves to the next warehouse in the Allocation rule. This means that if the next warehouse is:
  • a ‘Direct’ warehouse, the order is fulfilled from this warehouse
  • a ‘Direct, then confirm’ warehouse, the flow is repeated. So, the allocation changes to the next ‘Direct, then confirm’ warehouse and a request for confirmation is done

If no other warehouse is present, the order is set as a backorder, requiring manual handling.

Warehouses using the ‘Direct, then confirm’ Allocation policy can be physical stores. When set up as physical stores, you can choose to connect them to a Brick and mortar.

What does the ‘Direct, then confirm’ flow look like?

Depending on the Allocation rule setup the order flow can behave differently. Let’s explore some scenarios of Allocation rule setups and the way the order flow changes:

Scenario 1: Two ‘Direct, then confirm’ warehouses with different priorities

In this scenario, the Allocation rule contains two ‘Direct, then confirm’ warehouses with different priorities, as seen below:

The Order flow is as follows:

1. The allocation is done towards ‘Direct, then confirm 1’ warehouse and a request to confirm the allocation is also sent

2. The following information is available on the Order summary:

   

   • The 'Direct, then confirm status' is set to 'Waiting for confirmation'
   • The ‘Allocation rule’ provides an overview of the warehouses used
   • If you click on 'Waiting for confirmation', you see the following:
     • The allocation request and which warehouse it was done against
     • The time out set for the allocation request
     • Which warehouse the products were allocated to
     • The ‘Warehouse allocation’ button redirects to the ‘Warehouse’ pop-up, which can also be accessed through the ‘Ordered products’ section. This provides a summary of all items in the order along with their quantities, which warehouse they are allocated to and the allocation status

3. Next, the following scenarios are possible:

   • Confirm: The ‘Direct, then confirm 1’ warehouse can confirm the request. The stock allocation stays on ‘Direct, then confirm 1’ and the regular order flow commences

   • Reject: The ‘Direct, then confirm 1’ warehouse can reject the request. The stock is released back to ‘Direct, then confirm 1’, the allocation changes to ‘Direct, then confirm 2’ and a request is done to this warehouse. The 'Direct, then confirm status' is still set to 'Waiting for confirmation' showing the ‘Direct, then confirm 2’ warehouse and its timeout: The following are possible:

     • Confirm: The ‘Direct, then confirm 2’ warehouse can confirm the request. The stock allocation stays on ‘Direct, then confirm 2’ and the regular order flow commences
     • Reject: The ‘Direct, then confirm 2’ warehouse can reject the request. The stock is released back to ‘Direct, then confirm 2’ and the order is set as a backorder, requiring manual handling
     • Time out: The ‘Direct, then confirm 2’ warehouse can time out. The stock is released back to ‘Direct, then confirm 2’ and the order is set as a backorder, requiring manual handling

   • Time out: The request to the ‘Direct, then confirm 1’ warehouse can time out. The stock allocation changes to ‘Direct, then confirm 2’ and a request is done to this warehouse . The 'Direct, then confirm status' is still set to 'Waiting for confirmation' showing the ‘Direct, then confirm 2’ warehouse and its timeout:

   The following are possible:

   • Confirm: Here we have 2 possibilities. The time out for ‘Direct, then confirm 1’ has passed, however, this warehouse can still confirm the allocation for this order. Therefore, both ‘Direct, then confirm 1’ and ‘Direct, then confirm 2’ warehouse can confirm, and the order is fulfilled from the warehouse that confirms first:

     • If the ‘Direct, then confirm 2’ warehouse confirms first, the stock allocation stays on it and the regular order flow commences
     • If the ‘Direct, then confirm 1’ warehouse confirms first, the stock allocation changes to it and the regular order flow commences

   • Reject: The ‘Direct, then confirm 2’ warehouse can reject the request. The order is set as a backorder, requiring manual handling. It is no longer possible for ‘Direct, then confirm 1’ to confirm the order

   • Time out: The ‘Direct, then confirm 2’ warehouse can time out. The order is set as a backorder, requiring manual handling. It is no longer possible for ‘Direct, then confirm 1’ to confirm the order

4. Depending on whether the allocation was confirmed, rejected or timed out, the ‘Direct, then confirm status’ changes to ‘Confirmed’ or ‘Rejected’ as seen in the screenshots below:

   • ‘Confirmed’ for orders with an confirmed request:

   

   • ‘Rejected’ for orders with a rejected or timed out request:

   

Scenario 2: Two ‘Direct, then confirm’ warehouses sharing priority

In this scenario, the Allocation rule contains two ‘Direct, then confirm’ warehouses sharing the same priority, as seen below:

The Order flow is as follows:

1. The allocation is done towards ‘Direct, then confirm 1’ warehouse and a request is done to both ‘Direct, then confirm 1’ and ‘Direct, then confirm 2’ warehouses

2. The following information is available on the Order summary:

   

   • The 'Direct, then confirm status' is set to 'Waiting for confirmation'
   • The ‘Allocation rule’ provides an overview of the warehouses used
   • If you click on 'Waiting for confirmation', you see the following:
     • The allocation request and which warehouse it was done against
     • The time out set for the allocation request
     • Which warehouse the products were allocated to
     • The ‘Warehouse allocation’ button redirects to the ‘Warehouse’ pop-up, which can also be accessed through the ‘Ordered products’ section. This provides a summary of all items in the order along with their quantities, which warehouse they are allocated to and the allocation status

3. Next, the following scenarios are possible:

   • Confirm: Both warehouses can confirm, and the order is fulfilled from the warehouse that confirms first:
     • If the ‘Direct, then confirm 1’ warehouse confirms first, the stock allocation stays on it and the regular order flow commences
     • If the ‘Direct, then confirm 2’ warehouse confirms first, the stock is released back to ‘Direct, then confirm 1’, changes to ‘Direct, then confirm 2’ and the regular order flow commences
   • Reject: If both warehouses reject the order, the order is set as a backorder, requiring manual handling. If one of the two rejects, the other can still confirm the order.
   • Time out: The time outs of both warehouses can pass. The order is set as a backorder, requiring manual handling

4. Depending on whether the allocation was confirmed, rejected or timed out, the ‘Direct, then confirm status’ changes to ‘Confirmed’ or ‘Rejected’ as seen in the screenshots below:

• ‘Confirmed’ for orders with an confirmed request:

• ‘Rejected’ for orders with a rejected or timed out request:

Scenario 3: Direct warehouse allocation

In this scenario, the Allocation rule contains one ‘Direct’ and one ‘Direct, then confirm’ warehouse, as seen below:

Since the ‘Direct’ warehouse is first, the allocation is done towards it. The regular order flow commences and the order is fulfilled from the ‘Direct’ warehouse.

Only once the ‘Direct’ warehouse is out of stock, the ‘Direct, the confirm’ warehouse is used, in which case the ‘Direct, then confirm’ flow commences, where the warehouse can confirm, reject or time out.

Good to know

• Before you start using 'Direct, then confirm' policy please make sure that both Centra and PSP of choice are supporting multiple captures.
• Allocation rules using ‘Direct, then confirm’ warehouses work with the ‘Optimization-driven’ allocation type. Read more about this type here. This means that items are allocated from the warehouse that can fulfill the biggest part of the order regardless of the warehouse priority
  • Warehouse priority is only taken into consideration when two or more warehouses can fulfill the same part of the order or the entire order. The allocation is made and the request is done to the warehouse holding the highest priority
• Time outs act as delays from having an allocation request done to the next warehouse. Therefore, warehouses can confirm or reject the request after the time out. The exception is the last warehouse that has a request:
  • When the time out of the last warehouse is reached, it acts as an auto-reject. The order then is set to backorder and needs to be handled manually
• Warehouses that have rejected the request, do not have new requests for the same orders
• Split allocations are possible with the ‘Direct, then confirm’ flow. This means that allocations on an order can be partially confirmed, rejected or timed out. Do note that in case of unavoidable split, Centra automatically allocates parts of the order to the most suitable warehouses by following the rules of optimization-driven allocation type - so the maximum possible quantity is allocated from the least number of warehouses. If split allocation happens towards a 'Direct, then confirm' warehouse the PoS can only confirm or reject the requested portion of the order
• You can trigger the ‘Direct, then confirm’ flow in the Centra backend by creating an order that uses a respective Allocation rule. This means that requests are done to the ‘Direct, then confirm’ warehouses and they can confirm, reject or time out. Find out more below about other actions on an order/shipment:
  • Allocating to a ‘Direct, then confirm’ warehouse is possible after an order is placed, by selecting the ‘Direct, then confirm’ warehouse in the dropdown menu of the ‘Allocate’ pop-up. This generates a request to confirm the allocation and the time out can be adjusted in the pop-up. The same applies when adding more products or restoring canceled products on an existing order
  • It is possible to unallocate/return/cancel to a ‘Direct, then confirm’ warehouse, either by using the ‘Release items back to warehouse’ if the allocation was done to this warehouse or by selecting the ‘Direct, then confirm’ warehouse of your choice through the ‘Send items to a different warehouse’ option
• When a ‘Direct, then confirm’ warehouse rejects the order allocation, it is excluded from the fulfillment candidates. This means that if requests are done again, for example, in the case of split allocations, ‘Direct, then confirm’ warehouses that rejected do not have an allocation request
• Read more about the technical implementation of the ‘Direct, then confirm’ flow here
• The ‘Direct, then confirm’ flow is not supported in Wholesale
• If the store setting ‘Direct to shipment’ is set to Yes, only confirmed allocations are added to the shipments created automatically. The option selected in the ‘Only direct to shipment if allocated’ store setting does not interfere with this. Therefore, since unconfirmed allocations are not added to the shipment, we recommend that the PoS or another integration is used to handle the shipment creation for items shipped from 'Direct, then confirm' warehouses in order to streamline automations
• Ingrid can be used for 'Pick up in store' and 'Ship from store' omnichannel flows. We recommend testing the entire flow in your QA during the implementation process of such flows to ensure smooth operations. However, Ingrid's pre-checkout split functionality that allows brands to collect multiple shipping costs in case of split shipments is not supported.
• Bundles are not supported by the ‘Direct, then confirm’ flow. This means that if a 'Direct, then confirm' warehouse is added to a Default Allocation rule, the flow is skipped for bundles. Only allocations to 'Direct' warehouses work in this case
• The integration used to update stock is required to do regular stock updates in Centra. We recommend that these updates take place on every stock change in the physical store. This minimizes the risk of overselling.