If you take away one mental model from working with Advanced Warehouse Management in Dynamics 365 Supply Chain Management, let it be this: almost every piece of physical movement in your warehouse is governed by two configuration tables working as a pair. Work templates decide what work gets created and how it is structured. Location directives decide where that work goes — which locations to pick from and which locations to put to. Get these two right and the rest of WMS tends to fall into place; get them wrong and you spend your days firefighting "no work could be created" and "no locations could be found" errors.
When a source document triggers warehouse work, a sales order release, a transfer order, a production picking list, a purchase order receipt, the system runs a sequence. First it looks for a work template that matches the work order type and the query criteria. Within that template, each work line of type Pick or Put references a location directive code (or none). For each pick/put line, the system then evaluates location directives filtered by work order type and matched by their own query, walking the directive's lines and actions to resolve an actual location.
Understanding that flow is what lets you debug quickly. If no work is created at all, your problem is at the work template level. If work is created but the system cannot find a from- or to-location, your problem is in the location directives.
A work template is defined per work order type (Sales orders, Transfer issue, Finished goods put away, Raw material picking, Cycle counting, and so on). Each template has a header with a sequence number and a query, plus work lines that almost always come in Pick/Put pairs.
Sequence and specificity. Templates are evaluated top-down by sequence number, and the first one whose query matches wins. Your most specific templates belong at the top and your catch-all default at the bottom. A classic mistake is putting a broad template above a specific one — the broad one always matches first and your specific logic never fires.
Use the query, not a proliferation of templates. I would rather maintain three well-queried templates than fifteen near-duplicates. Restrict on fields like warehouse, order type, mode of delivery, or inventory dimensions.
Work header breaks. This underused setting controls how the system groups transactions into individual work headers — by shipment, by load, by order, or by a quantity threshold. If pickers complain that one piece of work spans too many orders, or that they get too many tiny work headers, the fix is almost always a work header break configuration, not code.
Directive codes tie the rows to location logic. On each Pick and Put line you can assign a location directive code. Leave it blank and the system uses the first matching directive for that work order type; populate it and you get precise control over which directive fires.
A location directive answers two questions for every movement: where do I take inventory from, and where do I place it to. The structure is three levels deep. The header is scoped by work order type and a directive code, ordered by sequence. The lines define a quantity range (From qty / To qty) and stop-search behavior — this is where you handle partial-quantity logic. The location directive actions hold the actual rules: a query that filters candidate locations plus strategy settings.
For picking, the directive query is where you encode your strategy. Fixed picking faces filter to those locations for the item; floating lets the strategy choose. Built-in strategies: FEFO batch reservation, round up to full LP, match packing quantity, least picking effort by location; are selected on the action. FEFO is essential anywhere you carry batch-tracked items with shelf life. Use ordered actions to express "pick from the pick face first, then overflow to bulk": action 1 queries pick locations, a lower-priority action 2 queries bulk, and the system tries each in order until demand is satisfied.
Putaway is the mirror image and often the more business-critical of the two, because bad putaway logic quietly destroys your pick-path efficiency over months. Putaway respects the maximum quantity, volume, and weight on the location profile and the stocking limits, so if putaway "can't find a location," check whether locations are simply considered full. Location profiles also control mixing rules, whether you allow mixed items, batches, or inventory statuses in one location, and a directive targeting a profile that disallows mixing will skip occupied locations. The empty-location strategy with a query targeting empty bulk locations is the workhorse for reserve putaway; pair it with a fallback action that tops up partially filled locations if you want to consolidate.
When work or locations fail to resolve, I run through this in order. Is the item warehouse-management-enabled with a unit sequence group and reservation hierarchy - half of "no work" issues are item setup. Does a work template actually match, or is a higher-sequence template intercepting the work. Do the location directive quantity ranges cover the demand — a line that goes 1 to 10 silently fails an 11-unit pick if nothing covers the remainder. Is on-hand available at the right inventory status and in the expected dimensions, blocked or quarantined status and missing license plates are common culprits. Are target locations full per their profile and stocking limits. Finally, use the Work inquiry, the directive simulation, and the warehouse management execution logs to see exactly which directive and action evaluated and why it stopped.
I never let work template and location directive changes go straight to production untested. Build a small set of representative scenarios: a single-line order, a multi-line multi-quantity order, a batch-tracked item, a full-LP move, and an oversize/overflow case; and run each through a sandbox, watching the work generated and the locations chosen. Document the expected result for each before you run it, so you are verifying against intent rather than rationalizing whatever the system produced.
Work templates decide what work is created and how it is grouped; location directives decide where it goes - debug accordingly. Order matters everywhere: templates and directives are evaluated by sequence, and the first match wins, so put specific configurations above general ones. Lean on queries and work header breaks rather than dozens of near-duplicate templates. For picking, encode your strategy through ordered location directive actions; for putaway, capacity, stocking limits, and mixing rules quietly drive whether locations are even eligible. When something fails, walk the resolution flow top to bottom and use the execution logs rather than guessing. Master these two tables and the rest of Advanced WMS - wave processing, mobile device flows, replenishment, cycle counting - all hangs off the same logic in predictable ways.
If you take away one mental model from working with Advanced Warehouse Management in Dynamics 365 Supply Chain Management, let it be this: almost every piece of physical movement in your warehouse is governed by two configuration tables working as a pair. Work templates decide what work gets created and how it is structured. Location directives decide where that work goes — which locations to pick from and which locations to put to. Get these two right and the rest of WMS tends to fall into place; get them wrong and you spend your days firefighting "no work could be created" and "no locations could be found" errors.
When a source document triggers warehouse work, a sales order release, a transfer order, a production picking list, a purchase order receipt, the system runs a sequence. First it looks for a work template that matches the work order type and the query criteria. Within that template, each work line of type Pick or Put references a location directive code (or none). For each pick/put line, the system then evaluates location directives filtered by work order type and matched by their own query, walking the directive's lines and actions to resolve an actual location.
Understanding that flow is what lets you debug quickly. If no work is created at all, your problem is at the work template level. If work is created but the system cannot find a from- or to-location, your problem is in the location directives.
A work template is defined per work order type (Sales orders, Transfer issue, Finished goods put away, Raw material picking, Cycle counting, and so on). Each template has a header with a sequence number and a query, plus work lines that almost always come in Pick/Put pairs.
Sequence and specificity. Templates are evaluated top-down by sequence number, and the first one whose query matches wins. Your most specific templates belong at the top and your catch-all default at the bottom. A classic mistake is putting a broad template above a specific one — the broad one always matches first and your specific logic never fires.
Use the query, not a proliferation of templates. I would rather maintain three well-queried templates than fifteen near-duplicates. Restrict on fields like warehouse, order type, mode of delivery, or inventory dimensions.
Work header breaks. This underused setting controls how the system groups transactions into individual work headers — by shipment, by load, by order, or by a quantity threshold. If pickers complain that one piece of work spans too many orders, or that they get too many tiny work headers, the fix is almost always a work header break configuration, not code.
Directive codes tie the rows to location logic. On each Pick and Put line you can assign a location directive code. Leave it blank and the system uses the first matching directive for that work order type; populate it and you get precise control over which directive fires.
A location directive answers two questions for every movement: where do I take inventory from, and where do I place it to. The structure is three levels deep. The header is scoped by work order type and a directive code, ordered by sequence. The lines define a quantity range (From qty / To qty) and stop-search behavior — this is where you handle partial-quantity logic. The location directive actions hold the actual rules: a query that filters candidate locations plus strategy settings.
For picking, the directive query is where you encode your strategy. Fixed picking faces filter to those locations for the item; floating lets the strategy choose. Built-in strategies: FEFO batch reservation, round up to full LP, match packing quantity, least picking effort by location; are selected on the action. FEFO is essential anywhere you carry batch-tracked items with shelf life. Use ordered actions to express "pick from the pick face first, then overflow to bulk": action 1 queries pick locations, a lower-priority action 2 queries bulk, and the system tries each in order until demand is satisfied.
Putaway is the mirror image and often the more business-critical of the two, because bad putaway logic quietly destroys your pick-path efficiency over months. Putaway respects the maximum quantity, volume, and weight on the location profile and the stocking limits, so if putaway "can't find a location," check whether locations are simply considered full. Location profiles also control mixing rules, whether you allow mixed items, batches, or inventory statuses in one location, and a directive targeting a profile that disallows mixing will skip occupied locations. The empty-location strategy with a query targeting empty bulk locations is the workhorse for reserve putaway; pair it with a fallback action that tops up partially filled locations if you want to consolidate.
When work or locations fail to resolve, I run through this in order. Is the item warehouse-management-enabled with a unit sequence group and reservation hierarchy - half of "no work" issues are item setup. Does a work template actually match, or is a higher-sequence template intercepting the work. Do the location directive quantity ranges cover the demand — a line that goes 1 to 10 silently fails an 11-unit pick if nothing covers the remainder. Is on-hand available at the right inventory status and in the expected dimensions, blocked or quarantined status and missing license plates are common culprits. Are target locations full per their profile and stocking limits. Finally, use the Work inquiry, the directive simulation, and the warehouse management execution logs to see exactly which directive and action evaluated and why it stopped.
I never let work template and location directive changes go straight to production untested. Build a small set of representative scenarios: a single-line order, a multi-line multi-quantity order, a batch-tracked item, a full-LP move, and an oversize/overflow case; and run each through a sandbox, watching the work generated and the locations chosen. Document the expected result for each before you run it, so you are verifying against intent rather than rationalizing whatever the system produced.
Work templates decide what work is created and how it is grouped; location directives decide where it goes - debug accordingly. Order matters everywhere: templates and directives are evaluated by sequence, and the first match wins, so put specific configurations above general ones. Lean on queries and work header breaks rather than dozens of near-duplicate templates. For picking, encode your strategy through ordered location directive actions; for putaway, capacity, stocking limits, and mixing rules quietly drive whether locations are even eligible. When something fails, walk the resolution flow top to bottom and use the execution logs rather than guessing. Master these two tables and the rest of Advanced WMS - wave processing, mobile device flows, replenishment, cycle counting - all hangs off the same logic in predictable ways.
No replies yet. Be the first to respond!