How does Dynamics 365 Commerce decide how much stock each…

How does Dynamics 365 Commerce decide how much stock each store gets?

It does not decide. It divides.

You give the buyer's push a quantity and a method, and it splits that quantity across stores using a weight somebody typed. There are three methods, and all three reduce to that same shape.

A sourcing note first, because it governs everything below. The current page names one of the three methods and says the others exist without listing them. The enumeration and the weight mechanics are documented only on archived pages scoped to Dynamics AX 2012 R3, and each is attributed as archived where it is used. Chapter 7 covers that situation itself.

For the allocation analyst or merchandiser who owns the split. Dynamics 365 Commerce. 7 minute read.

The form, and two ways to enter a quantity

The current page puts it at Commerce headquarters > Buyer's push, and describes the purpose plainly:

"This article explains how to create and process a buyer's push to distribute products from one location to one or many stores… You can define multiple configurations and have the system suggest how to distribute the products, or manually enter where the products are distributed to and how much gets distributed to each store."

Note that the manual path is first-class: you can type the destinations and amounts yourself.

Two quantity fields behave differently. Pushed quantity is per line. Additional quantity to push is a total across lines, and the archived page describes what it does with it:

"To specify a total quantity for the transfer orders, enter the quantity in the Additional quantity to push field… The quantity that you enter is distributed proportionately among the products."

So there are two proportional splits happening in one form, and they are easy to conflate: Additional quantity to push spreads a total across products, and the Distribution method spreads each product's quantity across stores. Different axes, different mechanisms.

A third mode is easy to miss and matches how buyers actually work: "you can specify quantities manually on some of the lines, and then enter a number in the Additional quantity to push field for the remaining lines." Manual where you have a view, proportional for the rest.

Then Calculate quantities populates the lines and Create order commits them. There is also a read-back step worth building in: "To view the orders, on the Warehouse FastTab, select a store in the list, and then click Order." Checking two stores first is cheaper than recalling a transfer.

The three distribution methods

From the archived page, verbatim:

- "Replenishment rules – Distribute quantities based on replenishment rules." - "Location weight – Distribute quantities based on the proportional weights that are assigned to the stores." - "Fixed quantity for all – Distribute quantities equally among the stores."

Location weight is the one the current page names; the other two appear only in the archived enumeration.

Which stores are in scope depends on the method:

"If you selected Location weight or Fixed quantity for all, you can select a hierarchy of stores in the Replenishment hierarchy field. These are the stores that will receive the transferred products." "If you selected Replenishment rules, the replenishment rules determine which stores will receive the transferred products."

So a rule carries its own recipient list, and the other two take one from a hierarchy you choose. With rules, changing who receives stock means editing the rule; with the other two it means picking a different hierarchy at run time.

What a replenishment rule actually contains

This closes the argument, and it is the least-read page in the set.

"You can create replenishment rules to define inventory distribution that uses buyer's push or cross-docking. Rules can apply to specific retail stores or specific replenishment hierarchies."

A rule is a header and lines. Each line has a Type — either Replenishment hierarchy or Channel — then a Name selecting which one, and then:

"In the Weight field, specify a weight for the hierarchy or channel."

That is the whole content of a rule. A list of recipients, each with a number beside it.

One configuration precondition silently changes the answer:

"You can include a retail store in a replenishment hierarchy that is included in a replenishment rule. In this case, warehouses that are not identified as stores are excluded from calculations and the resulting quantities that are distributed."

And a warehouse is identified as a store by a checkbox: "select the Store check box on the Retail FastTab in the Warehouses form." Miss it and that location is quietly outside the calculation.

And the page carrying that field has a scope caveat of its own

This is a caveat on our own citation, and omitting it would make this article look better sourced than it is. The replenishment-rules page ends with:

"In Retail essentials, the form that you use to complete this task includes a subset of the controls that are available for other configurations of Retail. If a topic about this form describes controls that you don't see, it may be because you're using Retail essentials."

*So the page documenting the Weight field describes the form as it appears in Retail essentials — a reduced configuration* — and the note cuts both ways, warning that it may also describe controls such a user would not see.

Either way it is not a complete specification of the rule form in a full deployment. The field is not imaginary — the current page names store weights as its input — but the field list is a floor rather than a ceiling, and worth verifying on your own version.

Where the weight comes from

Not from anywhere clever:

"The default weight and default percentage that are used in replenishment rules are based on the replenishment weight that is defined on the Retail FastTab in the Warehouses form. You can also define a new or separate weight and percentage for each channel or hierarchy. The new values take precedence over the default weight and percentage."

A field on the warehouse record, overridable per channel or hierarchy. Somebody types it. Somebody types the override. Nothing recomputes either.

The current page confirms the concept is live rather than legacy, naming the same input while handing off its setup:

"This procedure doesn't include setup of data that can be used in the buyer's push, such as replenishment rules, organizational hierarchies, and store weights."

So all three methods are one shape

Put the pieces together and the three collapse:

Replenishment rules — What it divides by: A Weight per channel or hierarchy on the rule · Where that number came from: Typed on the rule, defaulting from the Warehouses form
Location weight — What it divides by: The proportional weights assigned to stores · Where that number came from: The same typed warehouse field
Fixed quantity for all — What it divides by: Nothing — an equal split · Where that number came from: No number needed

Two of the three divide by a number a person entered, and the third divides by store count. That is the entire decision surface for how much stock a store receives.

None of this is a defect. It is a distribution engine doing what one should: executing a rule faithfully, at scale, without argument. The question is what the rule was told, and by whom, and when.

Two mechanical outcomes worth having: "Regardless of the distribution method you select, one transfer order is created for each store", and "If the stores that are being distributed to are in another legal entity, sales orders and purchase orders are created."

What none of them reads

None of the three method descriptions references demand, sales history or sell-through. Nor does the Weight field, whose documented default is another typed field.

That absence is bounded to the three sourced pages and to the descriptions as written. It is deliberately not the broader claim, which would be false: Dynamics does have forecasting. Demand planning and a planning engine exist and are documented elsewhere.

The precise statement is the useful one. The forecast and the store split live in different places, and the split does not consult the forecast.

What we would do instead, and the check for Monday

How we would build it. Compute the weight instead of typing it. Read the sell-through Commerce already holds by store and by variant, derive a weight per store per style — and for apparel, per size — then write it back into the field the push already reads. The engine does not change and the form does not change; the number it divides by stops being a guess from go-live. We surround Commerce; we do not touch its core.

Status, stated plainly. Assortment & Space Optimizer is the named place this decision sits in our portfolio, and it is not one of the eight built products in our register. The paragraph above is how we architect this class of problem — a capability, not a shipped app. We build these on request, against your systems and your constraints, and we have no delivered retail engagements.

The check for Monday, and it needs nothing from us. Export your store weights and trailing sell-through by store for one high-volume style. Rank both, then find the largest disagreement — the store ranked high on weight and low on sell-through. It has been receiving stock it does not sell on every push since the weight was set, and the arithmetic on that one store usually decides whether this is worth solving.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want to know what the gap between your store weights and your sell-through is worth? Book a 15-minute call — we'll walk the method and the model with you, on your data if you bring it. No deck.

Sources

Push products from a distribution center to stores using buyer's push — ms.date 2026-02-11
Use buyer's push to distribute products — archived, Dynamics AX 2012, ms.date 2014-04-18
Set up replenishment rules (Retail essentials) — archived, Dynamics AX 2012 R3, ms.date 2014-08-15

How does Dynamics 365 Commerce decide how much stock each store gets?