Can an assortment control how much stock a store gets?

No.

The two surfaces touch at exactly one place — a checkbox called Respect assortments — and that checkbox can remove a store from a distribution. It cannot tell the distribution how much that store should receive.

The difference sounds pedantic until the season is over and you are looking at where the markdowns landed.

For the merchandiser or allocation analyst who owns both the range and the buy. Dynamics 365 Commerce. 6 minute read.

The short answer, and where the two surfaces meet

An assortment governs availability. Microsoft is unambiguous:

"Assortments determine which products are available at specific stores and during a specific period."

Quantity is not among its dimensions — chapter 0 walks the full field inventory. Quantity lives in a different form, Commerce headquarters > Buyer's push, which distributes a central buy and creates one transfer order per store.

On that form sits Respect assortments. It is the only field in either surface that reads the other one, which makes it the whole answer to this question.

What Respect assortments actually does

The current page lists the field and tells you to set it. The sentence describing its behaviour is on the archived page, and it is precise:

"To distribute the products to only the stores that have the products in their assortments, select the Respect assortments check box."

Read what that sentence governs. It governs which stores are distributed to. It says nothing about how much each one gets.

The mechanism is a membership test: is this product in this store's assortment, yes or no. Stores failing the test drop out of the distribution. Stores passing it are then sized by whichever Distribution method you chose — a replenishment rule, a proportional store weight, or an equal split. Chapter 4 takes those apart.

The assortment is consulted for eligibility and then it is finished. Nothing carries a category, an attribute or a hierarchy position forward into the quantity.

A veto, not a vote

This is the useful way to hold it, and it is worth stating precisely because it is the boundary the whole cluster sits on.

The assortment's only influence on quantity is subtractive. It can take a store to zero by excluding it. It cannot make a store's share larger, smaller or better-shaped.

So the two things a merchant wants from an assortment plan behave differently:

"These stores should not carry this style" — Supported. Leave the style out of their assortment and set the checkbox
"These stores should carry it deeper than those stores" — No field. Both sets pass the same membership test and are then sized by the same weight

That asymmetry is the point. A binary that gates participation is genuinely useful, and it is not a plan. A plan is a set of quantities, and the only quantity in this flow is one somebody typed.

The sequencing trap, and it is the practical reason this matters

Both halves of this are batch-driven, which creates an order of operations nobody documents in one place.

Publishing an assortment starts a scheduler: "When you publish an assortment, the assortment scheduler automatically runs." And an edit after publication does not propagate on its own — "If you make changes to an assortment that you already published or to the channels that the assortment is assigned to, you must update the assortment."

Now put those two facts beside the membership test. The filter reads assortment state, and assortment state is only as current as the last scheduler run.

Which gives a failure mode with no error message. Add a style to a store's assortment, do not republish, run the push with Respect assortments set — and that store fails a membership test it should have passed. It receives nothing. No warning fires, because from the flow's point of view the filter worked exactly as designed.

This chain is our inference, not Microsoft's sentence. Each link is quoted above; the conclusion is ours. The verification is cheap and it is the check at the end of this article.

The reverse also holds: remove a style from an assortment without republishing, and a store can still qualify for stock it is no longer meant to sell.

And eligibility is dated, which most people miss

Microsoft's definition carries a third dimension that gets read past: assortments determine availability "during a specific period."

So membership is not a permanent property of a store. It is a property of a store on a date. The distribution reads that state whenever you run it.

That gives a cleaner way to describe the whole mechanism. An assortment answers a yes-or-no question about a store, a product and a moment — and hands the answer to a form that then applies a number nobody recomputed. Every dimension the assortment carries is spent deciding whether, and none of it survives into how much.

For a seasonal range this is where the two halves fall out of step in practice. The assortment knows the season has a start and an end. The store weight does not — it is the same number in week one and week twelve.

One thing can size a store, and it is a person

If the assortment cannot size a store and the weight is typed once, it is worth being precise about what can change a single store's quantity on a single run. The answer is a human, line by line:

"To manually specify a quantity for each product, enter each quantity in the Pushed quantity column. The quantity must be less than the quantity in the On hand column."

And the two modes can be mixed:

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

So manual override is a first-class documented path, not a workaround. A buyer who knows a particular store needs more can type it.

That is worth saying plainly because it changes what the gap actually is. The gap is not that quantities cannot vary by store — they can, arbitrarily, by hand. The gap is that nothing computes them. Every deviation from the weight is a person's judgement typed into a column, unrecorded as to why, and unrepeatable next season unless the same person is there.

The membership test has a second dependency people miss

The filter checks whether a product is in a store's assortment. But a product can be in an assortment and still not be available to any channel:

"You can add products that aren't yet released to a legal entity to an assortment, and you can approve the assortment. However, until the products are released to a legal entity, they can't be made available to the channels."

So there are two ways to fail the same test, and they look identical from the buyer's push: the product is not in the assortment, or it is in the assortment and not released. Chapter 2 has the full diagnostic; the reason it matters here is that both produce a store receiving nothing, with no distinction between them at the point of allocation.

For a new style being allocated for the first time, the release path is the more likely of the two — and it is the one nobody checks, because the assortment looks correct.

What we would do instead, and the check for Monday

The gap here is not a missing field. It is that the eligibility test and the sizing decision are answered by two different kinds of thing — one a boolean somebody maintains, the other a weight somebody typed — and neither reads sales history.

How we would build it. Treat eligibility and depth as one decision computed from the same evidence. Read the sell-through Commerce already holds by store and by variant, decide which stores should carry a style and how deep each should go, then write the two halves back where Commerce reads them: the assortment for the boolean, the store weights for the quantity. The ERP keeps executing; the decision stops being two disconnected manual steps.

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. Take one style you added to a store's assortment in the last month. Confirm the assortment was republished after the edit, then look at that store's last transfer order for it. If the style was added but never republished and the store received nothing, you have found the failure mode above in your own data — and the fix is a scheduled job, not a purchase.

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, Dynamics AX 2012, ms.date 2014-04-18

Can an assortment control how much stock a store gets?