Why is the only page explaining store allocation scoped to…

Why is the only page explaining store allocation scoped to Dynamics AX 2012?

Because the current page does not explain it. It walks the clicks.

If you configure how stock is distributed from a distribution centre to stores in Dynamics 365 Commerce, and you want to know what the options in the Distribution field actually do, Microsoft Learn routes you to a page it marks as not being updated and scopes to a product generation two names ago.

This is a claim about documentation, and every part of it is checkable in about two clicks.

For the partner, consultant or functional lead who owns a Commerce allocation build. Dynamics 365 Commerce. 6 minute read.

What the current page contains

The current article is commerce/tasks/push-products-distribution-center-store-buyers-push, stamped February 2026. Its own metadata puts it at 319 words.

It is a task page and it does that job: navigate to Commerce headquarters > Buyer's push, set a site and warehouse, add items, enter a Pushed quantity or an Additional quantity to push, choose a Distribution method, optionally pick a Replenishment hierarchy, set Respect assortments, then Calculate quantities and Create order.

It names one value for the Distribution field — Location weight — and then says this:

"You can select the other types to use other rules for the distribution."

It does not say what they are. It also hands off the inputs that carry the decision:

"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."

Both of those sentences are reasonable for a task page. Together they mean the current documentation tells you which buttons to press and not what the system will do.

Where the rest is documented

The enumeration exists. It is on dynamicsax-2012/appuser-itpro/use-buyer-s-push-to-distribute-products, and that page identifies itself clearly:

"This content is archived and is not being updated. For the latest documentation, see Microsoft Dynamics 365 product documentation."

"Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack"

Its metadata carries is_archived: true and ROBOTS: NOINDEX,NOFOLLOW, and its date is 18 April 2014.

That page lists all three distribution methods. A second archived page, set-up-replenishment-rules-retail-essentials, dated 15 August 2014 and scoped to AX 2012 R3, is where the Weight field and its default from the Warehouses form are documented. Chapter 4 quotes both.

So the two documents that explain how allocation quantities are actually derived are twelve years old, excluded from search indexing, and explicitly not maintained.

And one of the two archived pages is scoped narrower still

The replenishment-rules page is not simply old. It closes with this:

"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."

Retail essentials was a simplified configuration. So the only page documenting the Weight field — the number that decides how much stock each store receives — describes that form as it appeared in a reduced edition of a product generation that is two names out of date.

That is a sharper statement of the gap than "the page is old", and it cuts both ways honestly: the note also warns that the page may describe controls a Retail essentials user would not see, so it is not reliably a subset in either direction. What it is not is a specification of the form in a current full deployment.

The field names are identical

This is worth stating precisely, because it is the observation that makes the situation interesting rather than merely untidy.

Comparing the 2026 page against the 2014 page, these field and command names appear on both: Pushed quantity, Additional quantity to push, Replenishment hierarchy, Respect assortments, Calculate quantities, Create order.

Six names, unchanged across the two documents. What did change is the menu path — Retail > Common > Replenishment > Buyer's push in AX 2012, Commerce headquarters > Buyer's push today — and the length of the prose, which went from 491 words to 319.

What this is evidence of, and what it is not

Here is the discipline that keeps this article defensible, and it is worth being explicit about.

What the evidence supports: the current documentation for this form does not enumerate the options in one of its own fields, and the only enumeration Microsoft publishes is on an archived page scoped to AX 2012. That is a statement about documents, verifiable by opening them.

What the evidence does not support: that the feature has not changed since 2014. We are not claiming that, and the identical field names are not proof of it. Names outlive implementations. A field called Location weight in 2026 may behave differently from the one described in 2014, and no page we opened tells us either way.

The honest position is narrower and more useful than the dramatic one: there is a documentation gap on a live feature, and it sits exactly where a practitioner needs a decision. That is enough. Inflating it into an abandonment claim would be unsupported and would be the first thing challenged.

Why this matters on a project

For anyone delivering a Commerce build, the consequence is not academic.

Configuration decisions get justified by documentation. A design note that cites a page headed AX 2012 R3 is citing a document about a different product generation, and that will not survive review — nor should it. But the alternative on offer is a 319-word task page that does not describe the behaviour, so the citation gap is real rather than a matter of diligence.

The second consequence is knowledge risk. Where documentation does not describe behaviour, the behaviour is known by whoever tested it. That knowledge is held by a person, and people roll off projects. Chapter 6 makes the same observation about property scope, and it is the same shape: an undocumented mechanism becomes tribal knowledge, and tribal knowledge leaves.

What to do about it

Three things, and none of them requires software.

Test the field in a sandbox on your own version and record what each option does with a known quantity across a known set of stores. That takes an afternoon and produces documentation that is more current than Learn for your build.

Record the version you tested against. This is the part people skip, and it is what separates a useful note from a future version of the same problem. A behaviour note without a version stamp becomes the 2014 page in about three years.

Treat the store weights as a documented artefact in their own right. The current page names them as setup data and does not describe them; chapter 4 covers what they are. If your build depends on numbers whose derivation is nowhere written down, that is worth fixing before go-live rather than after.

One thing we would not do: knock the implementation for citing what was available. The gap is in the documentation, not in anybody's diligence.

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, ms.date 2014-04-18
Set up replenishment rules (Retail essentials) — archived, ms.date 2014-08-15

Why is the only page explaining store allocation scoped to Dynamics AX 2012?