The store got the style. It got the wrong sizes.
Dynamics 365 Commerce records which products a channel carries and between which dates. It executes that faithfully. What it does not hold anywhere in that record is how much of each, in which sizes, at which store — the three numbers that decide whether a run sells through or gets marked down.
Commerce does assortment planning, and says so
Start with the concession, because the gap only matters once the capability is clear. The phrase “assortment planning” is Microsoft’s own, on current documentation, describing what a retail category hierarchy is for.
“This hierarchy type is for merchandising, pricing and promotions, reporting, and assortment planning.”
So this page does not claim Commerce lacks assortment planning. It claims something narrower and checkable: look at what the records actually hold.
A category node holds
- A name and a description
- A friendly name for the channel
- Keywords for search and merchandising
- A display order
An assortment holds
- A channel, or a group of them
- A product, or a category of them
- A date range it is valid for
Every one of those is an identifier or a membership. Not one is a quantity, a forecast, or a rate of sale. The plan is named, and it is never modelled.
Breadth is modelled. Depth is a typed weight.
Breadth — which products a channel carries — is a real decision and Commerce models it directly. Depth is the other half, and it is answered somewhere else: in replenishment, by a weight applied down a hierarchy.
A weight is a reasonable way to split a quantity when you have nothing better. The difficulty is that it is typically set once, applied to every store in a band, and left. It does not know that one of those stores sells the size run differently, or that a category has moved since the weight was chosen.
The ERP knows which stores carry the product. The margin lives in how many each one should have had.
What Dynamics manages
- Which channels carry which products, and when
- The category structure merchandising is organised by
- Replenishment that executes the parameters it is given
What it does not decide
- How deep to go per channel, from that channel's own sales
- Which of the products in an assortment earn their space
- When a weight set at go-live stopped describing reality
Five decisions, and each one constrains the next
Apparel is where the gap costs the most, because a garment is not one product. It is a style in a colour across a size run, and every one of those dimensions is a separate decision that Dynamics records and does not derive. Get the fourth one wrong and the first three stop mattering — the store received the right style, in the right colour, in sizes nobody there wears.
Allocation
How much of this style goes to which store?
The quantity split. Dynamics executes the split you give it; the weight behind it is usually set once and applied to every store in a band.
Size curve
Which sizes, in what ratio, for this store?
The dimension that turns a good allocation into a bad one. A national curve sent to every door guarantees a broken size run somewhere, and broken runs are what get marked down.
Design
What did the last run tell us to make?
Sell-through by size, colour and fit is evidence about the next buy. It sits in transactional history and is rarely read back into the design decision. We have not researched this surface in Dynamics yet, and say so rather than implying depth we do not have.
Store clustering
Which stores actually behave alike?
Clusters are usually drawn by region or by revenue band. Neither predicts what a store sells. The clustering that matters is the one derived from rate of sale by size and category.
Digital search merchandising
What does the channel surface, and in what order?
The category hierarchy carries keywords and a display order. What it does not carry is which arrangement sold, which makes ordering an opinion rather than a measurement. Search relevance itself is unresearched on our side — the same honest gap as design.
The chain runs one way. A size curve computed on the wrong store cluster produces a worse allocation than no curve at all, because it is confidently wrong at every door in the group. That is why we start at the clustering and work outward, rather than optimising the number a merchandiser already argues about.
Three of these five are written up in depth below. Design and search relevance are not: we have not researched those surfaces in Dynamics, and naming a decision we can describe is different from claiming we have studied it. They are in the chain because leaving them out would misrepresent how the decisions constrain each other — not because there is an article behind them.
Beside the ERP, not inside it
The Assortment Optimizer reads sales history, assortments and category hierarchies, derives breadth and depth per channel, and writes the recommendation back into the records Dynamics already executes — behind an approval step. No overlayering, no change to the ERP core, and no replacement of your implementation partner.
The first engagement is read-only and answers one question before anything is recommended: which assortment decisions are currently being made by default rather than by intent? That is usually the finding that pays for the work, and it needs no write access to produce.
What we are not claiming
This is demo-ready and built on request. It is not a shipped product with a user base, and there is no sell-through or markdown figure on this page attributed to us — because we have not run it in your tenant. The numbers that matter come from a read of your own extract. Everything above about how Commerce behaves is quoted from Microsoft’s documentation and linked so you can check it rather than take our word.
Questions
Common questions
It does the part it names. Microsoft's own documentation describes the retail category hierarchy as being for merchandising, pricing and promotions, reporting, and assortment planning — the phrase is theirs, and any article denying it is wrong. What an assortment record holds is a channel, a product and a date range: which products are available where, and when. That is a membership decision. How many units of each, in which store, is a different question, and the fields for it are not in that record.
Breadth is which products a channel carries. Depth is how many of each it should hold. Dynamics 365 Commerce models breadth directly through assortments and executes them faithfully. Depth is derived elsewhere, in replenishment, from a typed weight or a hierarchy split — which means the number deciding how much stock a store receives is usually a parameter someone set rather than a figure computed from that store's own rate of sale.
Yes, and that is the design constraint. The optimizer reads sales history, assortments and category hierarchies, computes the recommendation outside the ERP core, and writes the answer back into the records Dynamics already executes, behind an approval step. No overlayering, no change to the ERP core, and no replacement of your implementation partner.
Transactional sales history by channel and product, your assortment and category hierarchy definitions, and the current replenishment parameters. The first pass is read-only: it establishes which assortment decisions are already being made by default rather than by intent, before anything is recommended.
The rest of the family
Replenishment runs to the safety stock you typed in. This derives that number from your own demand history instead of a planner's spreadsheet.
Business Central picks the lowest price you already entered. It never asks what the price should be.
The supported integration surface, the security model, and what we do not touch.
The method, written up
How breadth and depth are decided per channel, which Commerce records hold the answer, and where the recommendation is written back.
A Dynamics assortment decides whether a store may sell it, never how many
An assortment in Dynamics 365 Commerce maps channels to products and carries no quantity, depth or open-to-buy field. The quantity lives in a different form, and all three of its distribution methods resolve to a weight somebody typed.
Read more8 min read
Does Dynamics 365 Commerce do assortment planning?
Microsoft's documentation says a Commerce product hierarchy is for assortment planning. This is every field that surface actually gives you — and every one is a classification or an availability flag, never a quantity.
Read more8 min read
Can an assortment control how much stock a store gets?
No. The only place an assortment touches a quantity in Dynamics 365 Commerce is a checkbox called Respect assortments, and it is a veto rather than an input — it can remove a store from a distribution, never size one.
Read more7 min readWhy did my published assortment never reach the store?
Five documented reasons a published assortment does not appear at a channel in Dynamics 365 Commerce, the order to check them in, and the two pages that verify the result — including the one where an approved assortment is still correctly withheld.
Read more8 min read
How do you group stores for assortments, and what does the Retail assortment purpose do?
Store grouping in Dynamics 365 Commerce is an organization hierarchy you draw, and it does nothing for assortments until it carries the Retail assortment purpose. What inheritance gives you, and what no field computes.
Read more7 min readHow does Dynamics 365 Commerce decide how much stock each store gets?
Three distribution methods on the buyer's push, and all three resolve to a weight somebody typed — a replenishment rule carrying a Weight field, a proportional store weight, or an equal split. What each one reads, and what none of them reads.
Read more8 min read
Can you have more than one product hierarchy in Dynamics 365 Commerce?
You can build many category hierarchies in Dynamics 365 Commerce, but only one can carry the Product hierarchy type — one per organization. What that constrains for multi-banner retailers, and what the other two types are for.
Read more7 min readAre retail product properties shared across all your legal entities?
Retail product properties in Dynamics 365 Commerce are global — every legal entity shares the same value. Basic product properties are legal entity–specific. Same form, two scopes, and the difference is easy to read past.
Read more7 min read
Start with a read-only pass
The first pass is read-only: it establishes which assortment decisions are already being made by default rather than by intent, before anything is recommended.