Data Readiness for Merchandise Planning: The Fields, Grain and History a Plan Actually Needs

What data readiness means

That definition is deliberately about the plan rather than about the data. A product master can be complete, current and internally consistent and still not be ready, because readiness is a relationship between what the data carries and what the plan asks of it. The test is not whether the data is clean. The test is whether a planner can build a phased plan without stopping to rebuild something by hand. Every hand-rebuild is a step that has to be repeated every cycle, by the same person, from memory, and the count of those steps is what actually determines how long a planning cycle takes — not how automated the tooling looks.

This guide is a specification. It names the fields a plan cannot run without, the grain each one has to sit at, how much history is enough and what to do when there is not enough, and the failure modes that get through a load reporting zero errors. It deliberately does not ask which system owns any of these fields. A field can be authored in a PLM system, an ERP, a PIM, a warehouse management system or a spreadsheet, and the specification is identical in every case — what the plan needs is the field, at the grain, with the history. Ownership is a separate question with a separate answer, and answering it here would produce a system map instead of a specification.

Two framing points before the spec itself.

The first is that grain is the only part of this that cannot be fixed later. A missing field can be backfilled — badly, but it can be done. A field held at the wrong grain cannot be. Sales recorded monthly cannot be split back into weeks without inventing a shape, and the invented shape is exactly the thing the history was supposed to supply. The rule is one line long: capture finer than you plan, because you can always roll up and you can never split down.

The second is that readiness is category-specific in its content and identical in its structure. The apparel spec below is the spine, because apparel is the deepest of the common structures. What each vertical changes is which axes exist and which fields carry them — covered in the vertical sections near the end, and in more depth for the hierarchy itself in merchandise hierarchy by vertical. The schema those levels hang off is the retail data model.

The minimum viable field set

Both halves matter and they fail differently. A missing product master field is loud — the plan cannot be written and somebody notices immediately. A history structure held at the wrong grain is quiet: the plan gets written, the numbers add up, and the shape is wrong. The loud failures cost days. The quiet ones cost a season.

The product master spec

These are the fields a plan cannot run without. Each row names why the plan needs it and what specifically degrades when it is absent or wrong — not "data quality suffers", but which planning step stops working.

Two of these rows fail in a particular way, and they fail for the same reason: they look like presentation rather than data, so nothing in a load treats their absence as an error.

Size sequence is the first. A size scale is not a set of labels, it is an ordered run, and the order carries the merchandising meaning. Sorted alphabetically, XS/S/M/L/XL becomes L, M, S, XL, XS. A size curve applied against that order puts the peak of the curve on L and M instead of M and S, and every downstream total still reconciles perfectly — the units are all there, they are simply on the wrong sizes. It is a quiet defect by construction — nothing downstream disagrees — and the only reliable fix is an explicit integer sequence stored alongside the label.

Lifecycle status is the second. It is usually derivable — a style with receipts in two seasons is carryover, a style with no prior receipts is new — and deriving it is not the same as having it. A derivation runs against whatever the history currently says, so a style that was carried over and then discontinued and then reinstated derives differently depending on when you ask. Store it.

The grain rules

Four structures carry the history. Each one has a grain, and each grain has a specific consequence when it is coarser than the plan.

Sales history: style-color, by week, by location

Below any of those three, phasing is guesswork.

Style-color because that is where money is committed. Week because plans are phased in weeks and monthly history cannot be split back into weeks — and because under the 4-5-4 family of conventions one month in each quarter carries five weeks rather than four, so two monthly figures inside a quarter are not comparable without a week count attached. The conventions and their traps are covered in the retail calendar guide. Location because the entire case for door clustering and differentiated allocation rests on variance between doors, and an aggregate that reads correct is routinely wrong at every individual location.

Sales history also has to carry units and value separately rather than one derived from the other, because the relationship between them is the realized AUR, and realized AUR is the fastest available read on whether a style sold or was sold down.

Returns: a lagged negative against the original selling week

A return recorded in the week it arrives is correct for cash and correct for the inventory position. It is wrong for demand, because it books a negative into a week in which nothing was sold.

Here is the arithmetic, with illustrative figures chosen because they divide cleanly. Not benchmarks, and not drawn from any brand. Take a style-color with 13 weeks of selling. Gross unit sales in the last three weeks run 120, 90 and 60. Returns arriving in those same three weeks — generated by the peak selling weeks four to five weeks earlier — run 140, 130 and 110. Recorded in the week of return, net demand for those weeks is −20, −40 and −50. The demand curve now ends below zero.

A phasing built on that curve plans zero receipts into a three-week window that actually sold 270 units gross. Recorded correctly, those same 380 returns are lagged back against the weeks that generated them, where they net against gross sales of several hundred units and reduce the peak slightly rather than inverting the tail. The requirement this creates is one field: the returns record has to carry the original order or transaction reference. Without it the lag cannot be reconstructed and no amount of downstream cleverness recovers the shape. Categories with a return rate concentrated in a narrow post-purchase window feel this hardest, and the mechanism is worked through further in the returns impact on planning.

On-order: held at the same grain as the plan

If the plan is written by month and the on-order is held by season, the open-to-buy cannot net. This is not a rounding problem, it is a structural one, and the arithmetic shows why.

Illustrative figures again, chosen to divide cleanly. A department carries a season receipt budget of 1,250,000 dollars at cost, against which 1,200,000 dollars is already on order. Held at season grain, the open-to-buy reads 50,000 dollars — tight, but positive, and a buyer would treat it as room to chase.

Split the same numbers by month against the monthly receipt plan:

Two of the three months are already over-committed by a combined 220,000 dollars, and the season figure is positive only because April is 270,000 dollars under-bought. The aggregate is arithmetically correct and operationally meaningless: the money is open in a month nobody wants receipts in, and closed in the two months that matter. The rule is that on-order must be held at the finest grain the plan is controlled at — usually style-color by expected receipt month — and dated to expected arrival rather than to the purchase order date.

Inventory positions: dated to the day

A month-end inventory snapshot supports a monthly financial plan and nothing else. Weeks of supply, sell-through against on-hand and any in-season reforecast all need a position that lines up with the week the sales sit in. A month-end position joined to a weekly sales history produces a coverage figure that is right once a month and drifting for the other three or four weeks — and the drift is largest in exactly the weeks when receipts land, which is when a planner is most likely to be looking.

History depth and restatement

Depth first, because it is the question that gets asked and the answer is shorter than expected.

Two comparable seasons is the working floor for a seasonal category; one is enough to start with reduced ambition. One season gives a level. Two give a shape, because with a single season the seasonal pattern and the growth trend cannot be separated — every one-off event in that year is silently promoted into a recurring pattern. Beyond three or four comparable seasons the marginal value falls off quickly for fashion product, and stays high for continuity and core, where a longer run genuinely stabilises the base.

The word doing the work in that sentence is comparable. Three years of history spanning two hierarchy reorganisations, a channel launch and a size-scale change is worth less than two clean seasons, because none of the older data can be compared to the newer data until it has been restated — and restatement is only possible if somebody stored the information needed to do it.

How to restate history onto a changed hierarchy

Assume the reorg has already happened, because it always has. The task is not to prevent it; it is to make last season readable through this season's structure.

Build the mapping at the level that actually moved. A reorg that splits a class in two does not move classes, it moves the style-colors underneath them. The mapping table is therefore keyed on style-color, not on the node that changed name, and its rows say: this style-color, in this season, sat under this old node and now sits under this new node.

Store the mapping as a table and apply it as a join at read time. Do not overwrite the historical records. Destructive restatement is attractive because it makes every downstream report work immediately, and it is a trap for three reasons: reports run before and after the change disagree with no way to reconcile them; the change cannot be reversed when the reorg is itself revised, which happens; and the mapping — the actual decision somebody made — exists nowhere afterwards, so the next reorg starts from scratch. A stored mapping can be corrected, versioned and audited. A destructive restatement is a decision with no record and no undo.

Version the mapping by season. The same style-color can map differently in different years, and a single flat old-to-new table quietly assumes it does not.

Handle the unmapped node explicitly. A genuinely new node has no antecedent. The answer is to borrow a proxy and label it — never to leave it blank, because blank is not neutral. A blank node inherits whatever the system does by default, and a common default is a flat spread across the season, which is itself a forecast that nobody made deliberately and nobody will remember is there. Choose the proxy on the mechanism that drives the shape — same price band, same delivery cadence, same channel mix — rather than on product similarity, record which proxy was used in the same mapping table, and set the date it gets replaced by the node's own first season of actuals.

Worked example: one style-color through a hierarchy reorg

Illustrative figures throughout, chosen because they divide cleanly. Not benchmarks, and not drawn from any brand.

A womenswear department reorganises one class. Last season, the class Woven Shirts carried three style-colors. This season the class has been split into Casual Woven and Workwear Woven, because the two were being merchandised differently and planned as one.

Last season's history, at style-color, grouped into three phases of a 13-week season — weeks 1 to 4, weeks 5 to 9, weeks 10 to 13:

The mapping table that has to exist:

Restated, Casual Woven is Ink plus Sand: 350 units in phase 1, 750 in phase 2, 1,300 in phase 3, for 2,400 units. Its phasing is 350/2,400 = 14.6 per cent, 750/2,400 = 31.3 per cent, 1,300/2,400 = 54.2 per cent. That is a strongly back-loaded shape, and it is the truth about the product that now sits in that node.

Without restatement, the planner has one usable prior-season shape — the old class total — and applies it: 1,200/5,000 = 24.0 per cent, 1,600/5,000 = 32.0 per cent, 2,200/5,000 = 44.0 per cent. The class shape is dragged forward by W-4425 Olive, a workwear style that sold flat across the season and has now moved to a different node entirely.

Apply both shapes to the same new-season plan of 3,000 units for Casual Woven:

The season total is identical, which is why this error survives every check that looks at totals. The phasing is wrong at both ends. Phase 1 is over-received by 282 units against a window that historically sells about 438 units in four weeks — roughly 110 a week — so the plan carries about two and a half extra weeks of cover from the first week of the season, at full price, on product that does not start selling properly until week 10. Phase 3 is short by 305 units in the weeks that actually sell, so the style goes thin in its own peak.

Both halves of that error point at the buy, and neither is a buy error. The season total was right. What was wrong was a shape borrowed from a class that no longer exists, and the only artifact that would have prevented it is a stored mapping table. The mechanics of building the phasing itself are covered in how to phase a sales plan.

Six failure modes that survive a clean-looking load

Each of these passes a load that reports zero errors, because none of them is a structural defect. They are semantic, and a loader checks structure.

1. The class that grew 100 per cent and the class that vanished

Symptom: two nodes with implausible year-on-year variances in the same reorg, one enormous and one negative.

A hierarchy reorg orphans prior-season history: the new node has no antecedent, so it reads as pure growth, while the retired node keeps the history and reads as collapse. The pair is the tell — they appear together and their magnitudes roughly offset. Fix by restating with a stored mapping before any comparison is run, not by explaining the variances individually in a review.

2. The impossible size curve

Symptom: a curve peaking at the end of the run, or two products in the same class whose "M" clearly means different things.

Two size scales collide on the same alpha labels. A woven top scale and a knit scale both run S through XL and are not the same garment measurements; a kids scale re-uses the same characters at completely different bodies. Merged on the label, they produce a blended curve that fits neither. The requirement is a scale identifier alongside the size label, and the size sequence stored per scale rather than derived from the label.

3. The five-week month that grew 25 per cent

Symptom: one month per quarter beating plan by roughly a quarter, every quarter, in every category at once.

A 4-5-4 fiscal week has been joined to a Gregorian order or receipt date. The five-week month gets a fifth week of sales compared against a four-week base, and the variance is arithmetic rather than commercial. It shows up as a suspiciously uniform pattern across unrelated categories, which is the signature of a calendar defect rather than a merchandising one. Every date joined into the planning history has to be resolved to a fiscal week first.

4. Sell-through above 100 per cent with stock on hand

Symptom: a style-color whose sell-through exceeds what it received, while inventory reports still show units.

Marketplace orders arrive twice — once through the wholesale feed as an order to a marketplace partner, and once through the DTC feed as a consumer sale of the same unit. The double-count inflates demand and destroys the channel mix, which then flows into every channel-differentiated depth decision. Fix by deciding once which feed owns marketplace units for planning purposes, and reconciling total planned demand against total units received as a standing check.

5. The margin that changes after the season closes

Symptom: planned margin holds all season and realized margin arrives lower, with no plan line explaining the gap.

Cost was captured at purchase-order date rather than at landed date. Freight, duty and any currency movement between commit and arrival land outside the planned cost, and because the gap accrues per receipt it is invisible until the receipts stop. The planning history needs landed cost per receipt, and the plan needs to be denominated in the same cost basis the actuals will be reported in. The related problem of a cost base that moves during the season is handled in planning margin on a moving cost base.

6. The promo calendar wearing a demand curve's clothes

Symptom: a phasing that spikes in the same weeks every year, in categories with no reason to be seasonal in those weeks.

Promotional periods were never flagged in the history, so the demand shape derived from it is a record of when the brand discounted rather than when customers wanted the product. Next season's plan then receives into last season's promotions, which guarantees the promotions repeat. The requirement is a promotional flag at the week and style-color level, with the discount depth attached, so that a baseline shape can be derived with promotional weeks either excluded or normalised. A demand shape has to be a shape, not a promo calendar.

What changes by vertical

The spec above is written in apparel vocabulary, because apparel carries the deepest set of axes and most planning language was written in it. What follows is what each adjacent vertical adds, removes or renames. In every case the structure is unchanged: fields, grain, history.

Footwear

Footwear doubles the grain rather than changing it. The size axis carries length and width as two dimensions, so a model-color resolves into a grid rather than a run, and a brand that fits properly cannot collapse width into an average without discarding the fit proposition it sells on. The unit of measure is the pair, not the unit, and the product master has to say so explicitly — a load that treats pairs as units in one feed and eaches in another produces a position that is out by a factor of two in a way no total reveals. Run integrity is the field nobody thinks to store: what matters operationally is complete runs remaining, which is derivable only if the size sequence and the scale are both present. See assortment planning for footwear brands.

Accessories & bags

The size dimension collapses, and the readiness question becomes what carries the variance in its place. Material and colorway carry it — a handbag in pebbled leather and the same silhouette in canvas are different costs, different lead times and different sell-through curves, and a master that treats material as a description rather than a planning field cannot separate them. The size field should be absent rather than present and empty; an empty axis makes every cell in the history thinner for no benefit. Two lifecycle clocks have to coexist in the same master, because hero colors run on a season and the evergreen core runs on continuity, so the season tag needs a value that means "no season" and it needs to be a real value rather than a null. See planning accessories lines.

Home & furniture

Configuration and finish replace size, and they behave differently from it: a sofa, loveseat and sectional component are related products a customer chooses between, not a run a single buy is distributed across. The master therefore needs configuration as a variant field rather than as a distribution axis. Container quantity is a field the apparel spec has no slot for and the plan genuinely needs — receipts arrive by container, cubic volume is the binding constraint, and a plan denominated only in units and dollars cannot tell a planner whether the next month's receipts physically fit. The other required addition is a flag separating stocked variants from made-to-order ones, because the two consume different things: inventory in one case, production capacity and lead time in the other. See merchandise planning for home and furniture brands.

Outdoor

Outdoor needs a specification axis that means something different per family — torso length on packs, capacity in litres, sleeper count on tents, temperature rating and length on bags — which means one shared "size" attribute across families produces a column with five meanings and no usable rollup. Store the specification type alongside the value. The lifecycle field is the model year, not the season, and the two must not be merged: a carryover model with no changes reads as a new introduction if the season tag is doing the work. Dealer prebook commitment dates and the counter-seasonal gap between order and sell window make the first-receipt date field load-bearing here in a way it is not in a category that flows continuously. See merchandise planning for outdoor brands.

Health & beauty

Shade is the colour analogue and it is not a free variant: shades form a ladder that has to be complete, so the master needs a shade sequence for the same reason apparel needs a size sequence, and the ladder position is what makes a gap at the ends visible as a merchandising failure rather than a stock-out. Dating and shelf life are required fields the apparel spec has no slot for — expiry, batch or lot, and period after opening. Their absence is not a reporting gap, it is a valuation problem: an overbought shade with a date attached is a write-off rather than a markdown, and a plan that cannot see the date plans an exit that is not available. Format and fill size occupy the size axis and are a real level, not a descriptor. See merchandise planning for health and beauty brands.

Sporting goods

Model year is a first-class field here, not a tag — it is the lifecycle clock, the boundary for like-for-like comparison, and the thing that makes the outgoing and incoming models comparable at all. Held as a text attribute on the description, it cannot be joined against, which is precisely when a model-year changeover starts being reconciled by hand. The fit axis is discipline-specific — bat length and weight, grip size, shaft flex, board length — and these do not roll up to each other, so the master needs a fit-axis type per discipline rather than one shared field. Dealer prebook data belongs in the on-order structure at the same grain as the plan, because in a prebook channel most of the season's commitment exists before the season opens. See merchandise planning for sporting goods brands.

The readiness checklist

Run this before a planning cycle, an implementation, or any exercise that will compare this season to last. Each line is answerable yes or no.

• →Every style-color in the plan carries a hierarchy node, a channel, a lifecycle status and a season or model-year tag.
• →Size scales are identified, and each scale stores an explicit size sequence as a number rather than relying on the label's sort order.
• →Landed cost exists per receipt, and the plan is denominated in the same cost basis the actuals will be reported in.
• →Ticket price is held per channel and market, not once per style-color.
• →First-receipt date exists per style-color per delivery, and phasing starts from it rather than from the season start.
• →Sales history is stored at style-color by week by location, with units and value held separately.
• →Every sales week resolves to a fiscal week, and every external date joined into the history is converted to a fiscal week before the join.
• →Returns carry the original order or transaction reference, and net demand is computed against the original selling week.
• →Promotional weeks are flagged at style-color and week, with discount depth attached.
• →On-order is held at the plan's own grain and dated to expected arrival, not to the purchase-order date.
• →Inventory positions are dated to the day, not to month end.
• →Marketplace units are counted once, and total planned demand reconciles to total units received.
• →At least two comparable seasons of history exist for each planning node, or the node is explicitly flagged as running on a proxy.
• →A mapping table exists from prior-season nodes to current nodes, keyed at the level that actually moved, versioned by season, and applied as a join rather than by overwriting history.
• →Every node with no antecedent names its proxy, and every plan line built on a proxy is visible as such.

The checklist is deliberately short and deliberately blunt. Readiness is binary per line and cumulative overall: a plan built on fourteen of these fifteen is not 93 per cent ready, it is a plan with one hand-rebuilt structure in it, and that structure is rebuilt from memory every cycle by whoever remembers.

Two closing points about how this fits the rest of the process.

Readiness is a precondition for automation, not a product of it. A system that automates the mechanical work of planning inherits whatever grain the history was captured at; it does not repair it. The separation between automating mechanical work and putting a recommendation where a decision is made — and which of the two to attempt first — is worked through in from reporting to decisions in planning.

Readiness is also the honest part of a software evaluation. Most of the work in standing up a planning process is on this page rather than in a vendor's feature list, and it is work that pays off regardless of what gets selected, because the fields and the grain are the same in a spreadsheet as in a platform. The evaluation criteria themselves are a separate exercise, covered in how to choose apparel merchandising planning software.