Skip to main content

Plan replenishment across warehouses

An item planned as Transfer is replenished from another warehouse rather than bought or made. That raises a question the item's own policy cannot answer: from which warehouse? The Distribution Network is where you answer it, once, for each pair of warehouses.

Until you do, a Transfer item is still planned — the plan works out that the destination will run short, and on what date — but the planned order it produces has no source warehouse, so there is nothing to build a transfer from. The suggestion sits in the Workbench and is skipped when you try to carry it out.

What a route is

A route is a one-way supply relationship between two of your warehouses:

  • Source Warehouse — stock is taken from here.
  • Destination Warehouse — stock is needed here.
  • Transfer Lead Time — how long stock takes to travel the route, in days.
  • Priority — which route the plan takes when more than one could supply the same destination.

Two things about routes surprise people, and both are deliberate:

  • A route belongs to the pair of warehouses, not to a product. One route serves every Transfer item planned into that destination. You do not create a route per SKU.
  • A route is directional. A route from Main to East does not let Main be resupplied from East. If stock genuinely moves both ways, see Cycles are refused below — the plan does not allow that pair.

Before you begin

  • You need at least two warehouses.
  • At least one item should have Procurement Type set to Transfer at the destination warehouse, otherwise no route is ever consulted. Make and Buy items ignore the distribution network entirely. See Set item planning policies.
  • Opening the page needs the View permission in the MRP Planning group. Adding, editing or deleting a route needs Run in the same group. Without Run the buttons are still on screen, but the save is refused.

Steps

  1. Go to Manufacturing → Planning, then click Distribution Network in the button bar above the page title.

    The page opens with a short How routes are used explainer, then the Routes list. With no routes set up yet, the list reads "No routes yet. Add one to say which warehouse supplies which, so Transfer products can be planned."

  2. Click Add Route.

  3. Choose the Source Warehouse — the warehouse stock is taken from.

  4. Choose the Destination Warehouse — the warehouse that runs short and needs resupplying. This is the warehouse the Transfer item is planned at.

  5. Enter the Transfer Lead Time (days) — real transit time between the two, as a whole number of days. Enter 0 if stock moves the same day.

  6. Enter a Priority as a whole number. Leave it at 0 when this is the only route into that destination; use it to rank routes when there is more than one. See Which route the plan takes.

  7. Click Add Route.

    The dialog closes, the list refreshes, and "Route added" confirms it. The route takes effect on the next planning run — it does not change planned orders that already exist.

The Add Route button stays disabled until the route makes sense, and hovering it explains what is missing — a warehouse not yet chosen, the same warehouse on both sides, a pair that already has a route, or a lead time that is not a whole number of days.

The Routes list

ColumnWhat it shows
Source WarehouseThe supplying warehouse, linked to its warehouse record
Destination WarehouseThe warehouse being resupplied, linked to its warehouse record
Transfer Lead TimeTransit time in days — "1 day", "4 days"
PriorityThe route's rank, plus a Preferred chip on the route that wins its destination
ActionsEdit and delete buttons for the row

The list is sorted by Priority ascending, so the route the plan actually takes is usually not the one nearest the top. That is what the Preferred chip is for.

The page loads the first 100 routes. If you have more, a line under the table says how many of the total are being shown, and no Preferred chip appears anywhere while the list is cut short — a route that was not loaded could outrank everything visible, and a wrong chip is worse than none.

Which route the plan takes

When a destination has more than one route into it, the plan takes the route with the highest Priority. A tie on priority is broken by the shortest Transfer Lead Time. Priority is a rank, not a limit: the plan uses one route per destination and does not split a transfer across two sources or fall back to the second route when the first is short of stock.

The winning route carries a Preferred chip in the Priority column. The chip appears only where a destination has two or more routes — a destination served by a single route has no competition to resolve.

note

Give competing routes distinct priorities. If two routes into the same destination share both the same priority and the same lead time, nothing further separates them, and which one the plan picks is not something you can rely on.

Lead time is what schedules the transfer

For a Transfer item, the route's Transfer Lead Time is the lead time the plan works with. It replaces whatever the item's policy would otherwise have produced through its Lead Time Source — a supplier's quoted days are meaningless for stock you already own and are only moving.

So the plan counts back from the date the destination needs the stock, over your planning calendar, and the release date it gives you is when the transfer has to leave the source warehouse. A route whose lead time is optimistic produces release dates that were never achievable, and a run that looks fine while the shelf goes empty. Set it to real transit time, including any handling at either end.

If the item's policy also carries a Safety Lead Time, that is added on top of the route's transit time. Safety Lead Time has no field in the planning policy dialog — the only way to set it is the planning-policies import and export round trip, described in Import MPS entries and planning policies.

A transfer also creates demand at the source

Planning a transfer into a destination does not make stock appear. The same quantity becomes demand for that product at the source warehouse, on the date the transfer is released — so the source warehouse's own plan sees it and covers it, buying or making the stock if that is what its policy says.

That is why the plan works through your warehouses in supply order: a destination is planned before the warehouse that supplies it, so by the time the source is planned, every transfer pulling stock out of it is already known.

Editing a route

In the route's Actions column, click the edit button (Edit route). The dialog opens with the route's current values, and every rule that applies to a new route applies to the edit — you cannot point it at a warehouse pair that already has a route, or at the same warehouse on both sides. "Route updated" confirms the save.

Edits apply from the next planning run. Changing a lead time does not re-schedule planned orders already on the board.

Removing a route

In the route's Actions column, click the delete button (Delete route). The confirmation names the route it is about to remove — "Delete the route Main Warehouse → East Coast DC?" — because on a list where several rows differ by one warehouse, a bare "are you sure?" is not a question anyone can answer.

caution

Deleting a route is not a neutral act. Transfer items planned into that destination lose their source warehouse at the next planning run, and their planned orders will not carry out. If the destination has another route into it, the plan falls back to the highest-priority one that remains. If it has none, the suggestions keep appearing and keep being skipped.

"Route deleted" confirms the removal.

Cycles are refused

The plan refuses any route that would let a warehouse end up supplying itself, directly or through a chain — A feeds B feeds A, or A feeds B feeds C feeds A. The route is rejected with the message "This edge would create a cycle in the distribution network." and nothing is saved.

This is a real protection, not a technicality. A transfer creates demand at its source warehouse, so a loop would have each warehouse's shortfall generating the other's, with no warehouse that can be planned first and no point at which the arithmetic settles. Supply has to come from somewhere outside the loop eventually.

If stock genuinely moves in both directions between two sites, keep the route for the direction that carries routine replenishment and move the occasional consignment the other way as a warehouse transfer you raise by hand.

When a Transfer order has no source

A Transfer planned order with no source warehouse is not a silent failure, but it is a quiet one — it only announces itself at carry out. Selecting it and clicking Carry Out produces a result like "4 released, 1 skipped (no source warehouse on the transfer)". Nothing was created for that row, and it is still there on the next run.

Two ways to resolve it:

  • Add the route here. The fix for every Transfer item planned into that warehouse, now and in future. Re-run the plan, and the suggestions come back with a source warehouse attached.
  • Set a source on the single order. In the Workbench, open the planned order and choose a Source Warehouse on it. That carries the one order out and nothing more — the next run plans the same item with no source again.

Once a Transfer order does have a source, carrying it out creates a draft warehouse transfer from the source warehouse to the destination, for the order's quantity, with its due date as the transfer's ETA. See Carry out planned orders.

Next steps

Last verified: