Multi-warehouse fulfilment for distributors on Dynamics 365

A distributor with one warehouse has an inventory problem. A distributor with five has a routing problem: which warehouse ships which line of which order, how stock moves between them, and what happens when the nearest one is short. Dynamics 365 models the structure well, but the routing decision itself is thinner than people assume, in both Supply Chain Management and Business Central. This guide covers how to set the structure up and what to do about the routing gap.

Structure: sites, warehouses, and what they mean

In Supply Chain Management, a site is a geographic or operational grouping with its own planning and costing context; a warehouse is a physical stock location within a site. Distributors typically get this right for the physical estate and wrong for the edge cases:

• Regional distribution centres are sites, each with a main warehouse. Straightforward.
• Cross-dock or transit stock should be a warehouse of type Transit under the receiving site, so that stock in transit between sites is visible and financially owned.
• Consignment at customer and van stock are warehouses, not sites, and they should not be picking-enabled unless someone actually picks there.
• Quarantine, returns, and damaged stock are separate warehouses or blocked locations, depending on whether the distributor runs advanced warehouse management.

In Business Central, the equivalent is locations, with stockkeeping units for location-specific replenishment parameters and in-transit locations for transfers. The locations and transfer routes guide covers the setup.

Where a sales line's warehouse comes from

This is the part that surprises distributors moving from a system with built-in sourcing. In Supply Chain Management, a sales order line's site and warehouse default from, in order, the customer's default site and warehouse, then the item's default order settings, with site-specific order settings overriding. There is no rule that says "ship from the warehouse nearest the delivery address". Distributed order management exists in Commerce for channel orders; it does not apply to ordinary sales orders.

Business Central is the same: location defaults from the customer, then the item, then the user's responsibility centre, and nothing looks at geography.

The practical patterns distributors use:

• Customer-driven defaults. Each customer account has a default warehouse matching their region. Works when customers have one ship-to; breaks for national accounts with many delivery addresses.
• Ship-to-driven defaults. For national accounts, either separate customer accounts per region (crude but zero customisation), or a small extension that sets the warehouse from an attribute on the delivery address. This is one of the most common small X++ or AL extensions in distribution, and it is worth doing early rather than living with manual overrides.
• Order-entry override with ATP. Sales staff check available-to-promise per warehouse on the line and change the warehouse when the default is short. Supply Chain Management shows ATP per warehouse on the line; the discipline is human.
• Automated sourcing — evaluate every line against stock, distance, and cost, and pick the best warehouse — is not in either product. It is an ISV order-management layer or a custom service, and most distributors do not need it until they have many warehouses and a genuine cost-to-serve problem.

Splitting an order across warehouses

Both products allow different lines of one order to ship from different warehouses; each line carries its own warehouse and generates its own picking. The parts that need policy:

• Delivery documents. Each warehouse produces its own packing slip or shipment, so the customer receives two deliveries with two documents. If the customer expects one consolidated delivery, either consolidate physically through one warehouse (transfer first, then ship) or accept two shipments and one invoice.
• Freight. Two shipments cost two freight charges. Supply Chain Management's transportation management can rate each shipment; whether the customer is charged once or twice is a commercial decision.
• Backorders. A line that cannot ship from its warehouse either waits (delivery remainder), moves to another warehouse (change the line's warehouse and re-reserve), or is transferred in. Distributors should decide the default per customer group and configure the delivery-remainder and partial-delivery settings on the customer accordingly.

Moving stock between warehouses

Transfer orders are the mechanism in both products: a shipment from one warehouse, an in-transit state, and a receipt at the other, with lead times per route. Supply Chain Management adds warehouse refilling: master planning can be configured so that a branch warehouse's coverage is satisfied by planned transfers from a designated main warehouse rather than by purchase orders, using the warehouse's refilling relationship and coverage settings. Set this up and the branch warehouses replenish from the hub automatically at every planning run; skip it and every branch creates its own purchase orders to the supplier, which is the number one cause of duplicate buying across a multi-warehouse estate.

Business Central handles the same idea through stockkeeping units with a replenishment system of Transfer and a transfer-from location. The planning worksheet then suggests transfer orders. Simpler, and adequate for a distributor with a hub and a few branches.

Cross-docking — receiving at the hub and moving straight to the branch or the customer without put-away — is a feature of advanced warehouse management in Supply Chain Management and of directed pick and put-away in BC, with the usual caveat that it only works when the demand exists in the system before the goods arrive.

Inventory visibility across the estate

Sales staff need one view of stock everywhere. Supply Chain Management's on-hand inquiry does it per item; the Inventory Visibility add-in gives a fast, cross-warehouse (and cross-legal-entity) picture suitable for portals and customer self-service. BC's item availability by location page does the equivalent for a smaller estate. Neither is a reason to build a data warehouse; both are a reason to make sure counts are accurate, because a visible wrong number is worse than an invisible one.

Sequencing a multi-warehouse rollout

Get the structure right first, including transit and quarantine warehouses. Then default warehouses by customer and item, with the ship-to extension if national accounts need it. Then refilling from the hub. Only then think about automated sourcing, and only if the exception queue from manual overrides is too big for the sales desk to handle. Distributors who buy a sourcing engine first usually find that the real problem was branch warehouses buying independently, which refilling would have fixed.