1. What is it?
Distributed order management (DOM) enables retailers to deliver stock to customers efficiently, across multiple warehouses/locations. It is possible to finetune the logic to business needs to achieve optimal lead times. This saves cost as it avoids inefficient displacement of stock and reduces manual labour for inventory management. DOM creates optimal routes between warehouses and ensures reservations across multiple warehouses. DOM also keeps track of the priority for stock reservation when multiple customers want to receive the same product. The principle “First come, first served” (FCFS) is applied. The customer priorities are maintained even when the stock moves between multiple warehouses, which improves on-time delivery (OTD). DOM is also flexible as it adapts to real time changes. Stock that is received unexpectedly, because of customer refunds, early suppliers or corrections based on inventory counts for example will affect existing routes if it improves the lead time.
2. Which scenarios are supported?
The DOM logic relies on the hub and spoke model. One central warehouse (hub) distributes stock to other non-central warehouse (spokes). It is assumed that new stock from suppliers is mainly received at the hub. All scenarios take into account that warehouses can belong to different financial entities.
Currently, the following scenarios are supported:
1. Retrieve stock from the hub warehouse to deliver it to a spoke warehouse.
Infographic
The most common scenario is that at a spoke warehouse not all products are available and that the hub offers the whole assortment. Therefore, stock has to be ordered from the central hub. It is crucial that reservations at the central hub are handled as fast as possible to avoid conflicting sales and false promises to customers. DOM handles the reservation at the central warehouse instantly and manages priorities if multiple customers exist for the same product. The route from the hub to the spoke warehouse is created and can be bundled with others for efficient internal logistics.
2. Retrieve stock from any spoke warehouse based on custom priorities and deliver it to the hub.
Infographic
This scenario is useful when low volume products are spread across multiple spokes and when the hub is used for dispatching. It allows to source products internally instead of waiting for a supplier to arrive and ensures a fast fulfillment. Spokes are prioritized based on their lead times for a specific product. This can also include a custom routing-schedule.
3. Retrieve stock from any spoke warehouse, ship it via the hub warehouse to eventually receive it at another spoke warehouse.
Infographic
To reduce the number of possible routes, stock is often delivered via the central hub. If a spoke warehouse “A” requires stock from spoke warehouse “B” then it can be delivered via hub. DOM handles both routes: From “B” to the hub and then from the hub to “A”. Also, logic is included to determine whether sourcing from “B” is actually faster than just waiting for the supplier that delivers new stock to the hub. The scheduled routes adapt to real time changes. An early/unexpected reception of new stock at the hub can automatically cancel the route from “B” to the hub. If multiple customers order stock via the hub for the same product, then their priority is kept intact. The customer that ordered first, is assigned the stock that arrives at the central warehouse first.
4. Retrieve stock from a custom source warehouse
Infographic
Sometimes it is not efficient to rely on the hub and spoke logic. For example, if two spoke warehouses are physically very close it does not make sense to ship via the hub. Therefore, it is possible to overwrite the logic and to define a custom source warehouse. DOM will create a direct route between both warehouses and ensure the reservations and priorities.
Not yet supported:
Currently, multiple hubs are not yet supported. In future updates, support for multiple hubs and multiple DOM configuration templates will be included.
3. Which components are needed
If you want to implement any of the scenarios above, make sure to add the following components to your application. As the features are constantly evolving it is recommended to choose the lastest CTP version.
M8694 - Novulo Distributed order management for sales lines, latest CTP, at least r229
M9669 - Novulo Hub and Spoke settings at warehouse, latest CTP, at least r7
M3344 - Novulo Voorraadmutaties en reserveringen, latest CTP, at least r1357
M3954 - Novulo Leveringsplanning bij verkoop, latest CTP, at least r395
M5210 - Novulo Voorraadleveringen voor mijn organisaties, latest CTP, at least r381
M6354 - Novulo Voorraadbestemmingen, latest CTP, at least r73
Optional:
M4446 - Novulo Dropshipments, r135+
Only add this component if you use internal drop shipments. For example, if the hub delivers directly to the customer for an order of a spoke warehouse. If the hub and the spoke belong to a different financial entity, an internal drop shipment is required to keep the finances in balance. Revision 135 or higher are compatible with M8694.
M9657 - Novulo Lead time optimization, r24+
This component adds extra features to facilitate the automated decision-making: Wait for internal stock vs wait for stock from the supplier. It requires high quality data of expected stock and internal routes. It is depended on the components below:
Dependencies:
M7523 - Novulo Vroegst mogelijke ophaal tijd bij product en voorraadlocatievoorraad
This component enables the calculation of the earliest possible date time for any product to be available for dispatch at the central warehouse. This time is crucial for determining whether to wait for a supplier or not and which internal warehouse to choose as a source.
The date time is calculated for:
- “Available stock” in warehouses, taking into account scheduled routes to the central warehouse, warehouse processing duration and “stock location processing duration”
- “Ordered stock” based on existing purchases
- “External stock” based on purchasing frequencies and average duration before receiving stock from the default supplier
M9665 - Novulo Route planning via warehouses, r20
Routes to the central warehouse influence the earliest pick-up time of products at the central warehouse. This component is required when you use M9657. A route stores information about the start and end date of a logistic route and all waypoint warehouses. A single route can be created manually or it can be created automatically based on a route plan. The current use cases include the scheduling and monitoring of logistic routes between warehouses and the estimation of interal lead times. Read more here: M9665 - Routes and route plans
M9700 - Novulo Update expected receiving date time of expected delivery lines, r10
This component helps with keeping the expected receiving times of stock up to date. It helps to keep the calculations for the lead time optimization accurate.
M9717 - Novulo Ensure expected delivery batches from and to addresses
When individual stock deliveries are created between warehouses based on the DOM process for many individual customers, it makes sense to not ship them individually but to bundle those internal deliveries from and to the same addresses. This component allows for automatic bundling and creates batches of expected deliveries.
4. How to configure it?
Some configuration is required to define your custom logic and preferences.
This instruction assumes that the following parts of your application have already been configured properly.
Prerequisites
- Basic logistic configuration: Warehouses with stock exist and it is possible to deliver stock between warehouses by manually creating “stock deliveries” (M5210).
- Basic sales configuration: It is possible to create and confirm sales orders. It is possible to deliver stock from the sales location directly to the customer, for example with a POS.
- Basic financial administration(s): All financial entities exist and journal entries are being created properly for intercompany purchases.
Basic configuration
First we will determine which warehouses should be considered as spokes and which warehouse is used as the central hub. Go to All settings > Warehouses > Hub and spoke settings
1. Is the only central hub warehouse
Turn on this checkmark for the only warehouse that you consider to be the central hub for all other warehouses. If this checkmark is turned off, the warehouse automatically considered as a spoke warehouse.
2. Use warehouse as a source for “Distributed order management” stock deliveries
Not all warehouses can be used to source stock internally. Some warehouses might be used for RMA only for example, or they are located to far away from the rest. Turn on this checkmark for all warehouses that can be used for stock retrieval.
Custom configuration
Now, we will fine tune the DOM logic to the logistic needs of your organization.
Go to All settings > General settings > Distributed order management
1. Max number of attempts
This is the maximum number of attempts that the DOM process will make to search for stock. For example, a customer might want 10 of the same product, but they are all distributed along 10 different warehouses. To reserve all stock, 10 individual attempts are required. Leave this setting at 100 as this should work for most use cases.
2. Stock delivery description
Define an expression that returns a suited name for the stock deliveries that are created as a result of the DOM functionality. For example, the default:
string:load("DOM for sales ").concat(this.sales_of_distributed_order_management.number.tostring()
3. Verbose logging when executed successfully
Enable this feature to see detailed log messages after executing DOM for a sales line. You will find these log messages at on the sales line page. They help with understanding how stock is being retrieved. Example:
"Distributed order management" has successfully been ensured for sales line with id "601" with the following result:
- Total quantity required at "A": 5.00
- Total quantity reserved at "A": 0
- Total quantity covered by stock destinations: 5.00
-> Stock destination with id "591" waits for a quantity of "5.00" to arrive from "HUB" by stock delivery with id "204".
4. Ensure DOM for sales line?
Create an expression to define under what conditions the DOM process should be executed. This expression is checked every time before DOM is executed for a sales line. You can filter out sales lines that are not related to stock products, have not been payed, or sales lines that exist because of administrative purposes. When the expression results in false, nothing happens to sales line and the DOM process is stopped.
Example:
boolean:and([
this.sales.sales_cancelled.equals(yesno:load(0)),
this.is_occasion_intake.equals(yesno:load(0)),
this.is_for_drop_shipment_by_external_supplier.equals(yesno:load(0)),
this.sales.is_delivery_completed.equals(yesno:load(0)),
boolean:or([
this.sales.is_for_intercompany_backorder.equals(yesno:load(0)),
this.sales.is_backorder_s_created_at_other_own_organizations.equals(yesno:load(0)),
this.sales.is_intercompany().equals(yesno:load(0)),
this.intercompany_purchase_line.dropshipment_sales_line().isnotnull()
])
])
5. Add log when a sales line is not part of DOM
When tweaking the expression of step 4, it is useful to see log messages for sales lines that have actively been filtered out. However, once the expression is working as intended those logs would create additional overhead that is not needed. So it is recommended to turn the checkmark on in the beginning and to turn it off once everything runs smoothly.
6. Automatically ensure “Distributed order management” for sales lines while updating the expected deliveries
DOM will be executed without a manual trigger when the expected deliveries of a sale are being processed. This is suited for most use cases. Be aware that your filter expression should be properly tested to prevent any undesired results before you turn on this setting.
7. Ensure “Distributed order management” after every commit of a sales line
If the frequency of triggering DOM is not enough based on the previous checkmark, this setting can be turned on. Be aware that the excessive execution of the DOM logic may have a negative impact on the performance. This checkmark is intended for debugging and advanced bug fixing with configuration only. When in doubt, leave this checkmark turned off.
8. Enable priorization of external stock over internal stock if applicable (requires M9657)
When enabled DOM takes into account internal routes to the hub, average logistic processing durations, existing purchases at suppliers, average purchasing frequencies and the willingness of customers to wait. If a customer is willing to wait, waiting for the supplier is the preferred option as it is cheaper than additional internal shipping. Otherwise, the fastest option for fulfillment is preferred. This feature leans on a lot of different data to make correct predictions. Only turn on this checkmark if you are sure that the underlying data is solid.
9. Consider stock that is already in transit to the central warehouse
When DOM is being executed all available stock in the available warehouses is considered for fulfillment. However, sometimes stock can be in between two warehouses when it is in transit. When this feature is enabled all stock that is in transit and is expected to arrive in the future is considered as a potential source for the fulfillment. The logic takes into account that other customers might already be waiting for the same stock.
10. Prevent the deletion of DOM stock delivery lines when peer-destinations with missing expectations exist
When the need for a product is cancelled, for example when a customer changes his mind, then any non-final reservations or deliveries of the DOM process are cancelled. This happens automatically when a sales line quantity is set to 0 or when the sales line is deleted.
It is possible that the stock was already halfway on its way. Those deliveries can’t be cancelled.
It is also possible that stock was requested and that another customer was also waiting for the same stock. In that case it does not make sense to cancel the old delivery as there still is a need. When you turn this checkmark on, then this scenario is taken into account. Old deliveries are only cleaned up when there are no “peers” that would benefit from it.
11. Show error when DOM results in destinations with missing reservations or expectations
Some products are considered scarce, as it is not easy to retrieve new stock via suppliers for example. This may be the case for unique refurbished products or end-of-life products that are no longer being produced. In that case it crucial for a sales agent to be informed about failed reservations. In that case another customer might have been a little quicker via another sales channel. The warning gives the sales agent the possibility to immediately offer alternatives to the customer and to prevent unnecessary refunds.
When this checkmark is enabled, an expression is required to determine whether the additional check is required. Fill in the “Execute check for missing expectations” expression. Example:
boolean:or([
this.product.is_occasion.equals(yesno:load(1)),
boolean:and([
this.product.is_end_of_life.equals(yesno:load(1)),
this.product.available_stock_for_warehouses({
warehouses,
this,
boolean:and([
this.is_active.equals(yesno:load(1)),
this.include_in_publishable_stock.equals(yesno:load(1))
])
}).round().islower(this.quantity.ceiling())
])
])
12. Only reserve stock destinations when a custom condition is met
Sometimes the reservation of stock has to be delayed. For example when a customer wants to receive large quantities but is willing to wait long enough until a supplier delivers new stock. In that case it is not desirable that all exisiting stock is blocked for the waiting customer as he will wait for the supplier anyway.
If you turn on this setting, an expression is required to determine whether a stock destination should be reserved or not. Fill in “Condition for reserving stock destination” with an expression that results in false when reservations should be blocked.
5. How to use/test it
As described above there are many different scenarios that are supported by the DOM process and the customizability ensures a lot of custom use cases. As this is a highly automated process, the ideal use case does not require manual intervention or additional steps on top of the existing logistic processes.
However, this chapter will explain features that might come in hand during the configuration process.
Debugging on a sales line page
To test your configuration, create a sales line and use the buttons on the sales line:
- Trigger the execution of the logic manually and check the last log message to validate the outcome.
- Undo the DOM process to correct mistakes or before restarting the execution.
- Use the “Verified manually” checkmark and the “DOM comment” to register explanations or to document manual actions.
View all “Sales lines of “Distributed order management””
Go to all views > Sales lines of “Distributed order management”. This overview shows all sales lines that have been processed with the DOM logic. Use columns like "Successfully ensured “Distributed order management” and custom filters to monitor potential errors that occur.
The button "Ensure “Distributed order management” allows for a quick correction of errors when DOM needs to be executed again for multiple sales lines.
Manage customer priorities per product
Go to any stock product that is part of the DOM process based on your configuration. Add the grid “Distributed order management stock destinations in %hub%” to the page. It can look like this:
For each customer that is still waiting for stock that will pass the central hub, at least one stock destination is present. The summary explains who is waiting, why and for how many products. For example “Customer waits for 1.00 out of 4.00 for sales 1234 on position 1 in “HUB””. This means that the customer has bought 4 products via sales 1234. 3 of those products have been reserved already at the central hub and one reservation is still missing. As the customer is the first one in the queue any new stock that arrives at the central hub will be reserved for him. The other customers in the queue will get their reservations later when new stock arrives.
If, for some reason, a customer is allowed to skip the queue, the button “Move all related stock destinations to position 1” can be pressed. This makes sure that this customer has the highest priority for new reservations across all related warehouses. This overview can be used by customer service to resolve issues.
6. Known issues
If reservations are created for a sales line which has “stock destinations”, the stock destinations are not deleted. This can happen when the “Delete reservations” button is used for a delivery and when new stock becomes available, which is then reserved via the “Create reservations” button on the expected delivery page. This can lead to sales lines that have already been fully reserved and delivered while they still have open stock destination, waiting for stock. These need to be cleaned up. Right now this can be done for example by configuring a scheduled task that starts a clean-up workflow from time to time.
The workflow should cache all deletable stock destinations and then delete them. Caching and deleting are basic features that can be used for workflows in any application.
Use this expression to see which stock destinations are affected and then delete them.
{
stockdestinations,
this,
boolean:and([
this.createdat.islower(parent.workflow.cutoffdate.todatetime_dte()),
this.stock_delivery_line_to_destine.isnull(),
boolean:not(this.sales_line_to_destine.isnull()),
this.sales_line_to_destine.fully_delivered(),
this.all_reservations_created.equals(yesno:load(0))
])
}
In the future, maybe a data process needs to run after adding new reservations. However, since this can heavily impact performance, first the urgency of this issue needs to be determined.