A Dynamics assortment decides whether a store may sell it…

A Dynamics assortment decides whether a store may sell it, never how many

Ask a merchant what they decide and you get four answers. Which stores behave alike. Which styles go in which of those groups. The size mix inside each style. And how much of the buy physically ships where.

Ask Dynamics 365 Commerce what it holds and you get two: a boolean — may this store sell this product, on these dates — and a weight somebody typed.

Both halves of that sentence are quoted from Microsoft below. The second half is quoted from a page Microsoft archived in 2014.

For the merchandising or pricing lead who owns range, depth and allocation. Dynamics 365 Commerce. 7 minute read.

An assortment answers whether, never how many

Two current pages define it, and they agree.

"Dynamics 365 Commerce provides assortments that you can use to manage product availability across channels. Assortments determine which products are available at specific stores and during a specific period."

"In Commerce, an assortment is a mapping of one or more channels (or groups of channels, when using organization hierarchies) to one or more products (or groups of products, when using category hierarchies)."

Three dimensions carry the decision: channel, product, date range. Quantity is not one of them. Neither is depth, breadth, budget or open-to-buy — no such field appears on either page.

The granularity does reach the size, and that is the trap. From the setup page: "An assortment can also include specific products and specific variants of products." In apparel a size is a product dimension, so a variant is a size.

An assortment can therefore state that size 6 is available in store 214. It cannot state that size 6 is a twelfth of the buy.

Assorted is not allocated, and the distance between those two words is where apparel margin goes. You sell out of 10 and 12 at full price and mark down the 6s and 18s you over-bought — and the ERP recorded every one of those decisions while making none of them.

One operational note. Publishing is a batch job, not a save: "When you publish an assortment, the assortment scheduler automatically runs." And edits afterwards do not propagate on their own — "you must update the assortment."

What Microsoft says a tight assortment is actually for

This is the single most revealing line in the documentation, and it is easy to walk past.

The Implementation considerations section on assortment management is not about merchandising outcomes. The heading is "Data replication and database size":

"Well-managed assortments reduce the amount of data that must be processed and replicated to channel and offline databases."

The documented reason to keep an assortment tight is till performance. Not margin, not markdown, not sell-through. Smaller channel and offline databases.

That heading tells you which layer this feature belongs to. It is availability plumbing, and it is good plumbing. It was never shaped to hold a merchandise plan, and reading it as one is how teams come to believe the plan exists somewhere.

Store grouping is a hierarchy somebody drew

Merchants cluster stores on behaviour — climate, demographics, volume, size mix. Commerce offers grouping, which is a different thing.

"By adding your channels to an organization hierarchy, you can assign assortments to groups of stores… Whenever a new channel is added to the high-level organization node, that channel automatically inherits any assortments that were assigned to the higher-level organization node."

Inheritance works. What is absent is any computation of membership. You draw the hierarchy.

There is a configuration gate worth knowing before go-live, because a hierarchy that looks right can do nothing at all:

"You can assign assortments only to channels that are included in an organization hierarchy that is assigned the Retail assortment purpose."

And Microsoft's own worked example of segmentation is the tell:

"You then define another assortment that includes only large sporting equipment. Only your larger stores receive this assortment."

Grouped by floor space, assigned by hand. That is the documented pattern for what a merchant calls clustering. It is a reasonable starting point and it is not a cluster analysis.

Three methods, and all three are a weight you type

Quantity lives in a different form: Commerce headquarters > Buyer's push. Pick a site and warehouse, add items, enter a Pushed quantity per line or an Additional quantity to push across lines, choose a Distribution method, set Respect assortments, then Calculate quantities and Create order. One transfer order per store.

That Respect assortments checkbox is the only place the two halves of this article meet — and it is a filter, not a plan.

The three distribution methods:

Replenishment rules — Distributes on rules you configured
Location weight — Distributes on "the proportional weights that are assigned to the stores"
Fixed quantity for all — Distributes "equally among the stores"

And a replenishment rule is itself a list of channels or hierarchies, each carrying a Weight:

"In the Weight field, specify a weight for the hierarchy or channel." "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."

So all three collapse into one shape: a number a person enters. A rule is typed weights, location weight is proportional to typed weights, and fixed quantity is an equal split. None of the three descriptions references demand, sales history or sell-through.

One line we are not writing: that Dynamics has no forecast. It does — demand planning and Planning Optimization are real and documented elsewhere. The narrower claim is the defensible one: these distribution methods, as documented, do not consume one.

The enumeration is scoped to AX 2012

Here is a fact about the documentation rather than the product, and it is checkable in two clicks.

The current buyer's-push page is stamped February 2026 and runs to 319 words. It names one value for the Distribution field — Location weight — then says only: "You can select the other types to use other rules for the distribution." It never lists them.

It also hands off the part that carries 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."

"Store weights" is named as the input by a current page, which is what makes the concept live rather than legacy.

But the table above, and the Weight field beneath it, are quoted from two pages that carry is_archived: true, state "This content is archived and is not being updated", and scope themselves to Microsoft Dynamics AX 2012 R3. They are dated April and August 2014.

The field names on the 2026 page and the 2014 page are identical: Pushed quantity, Additional quantity to push, Replenishment hierarchy, Respect assortments, Calculate quantities, Create order.

We are not claiming the product has not moved in twelve years. We are saying the only enumeration of that field's options on Microsoft Learn is twelve years old, and the current page defers the setup in a sentence. On a live project that matters: configuration decisions get justified by documentation, and a page headed AX 2012 is not documentation of what you are configuring. Test the Distribution field in a sandbox on your own version.

What we would reject

The obvious build is to extend the assortment entity with depth, budget and size-mix fields. It is possible, and it is the wrong build.

It puts a planning model inside the system of record, where it inherits the batch scheduler, the replication path and every platform update — and it is the customer's implementation partner who carries it through all of them. Least of all the partner who built the hierarchy correctly.

Dynamics is the system of record. A merchandise plan is a different kind of object. The assortment should keep doing what it is good at: availability, and the replication hygiene Microsoft documents.

How we build it, and the check for Monday

Read the transaction history Commerce already holds — sales by store, by variant, by week. Cluster stores on observed behaviour rather than on a hierarchy somebody drew, fit a size curve per style per cluster, and resolve breadth against depth on the buy.

Then write the result back into the surfaces Commerce already reads: the assortment for availability, and the store weights for the push. 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. Nothing here is a report on somebody's business.

The check for Monday, and it needs nothing from us. Pull your store weights. Pull trailing sell-through by store for the same period. Put them side by side. If the ranking disagrees, your allocation is running on a number that was true once.

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

Assortment management — ms.date 2026-01-15
Set up assortments — ms.date 2026-01-29
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, AX 2012, ms.date 2014-04-18
Set up replenishment rules (Retail essentials) — archived, AX 2012 R3, ms.date 2014-08-15

A Dynamics assortment decides whether a store may sell it, never how many