Seasonality in replenishment: planning the peak without drowning in stock

Inventory & replenishment · 10 min read

A peak breaks replenishment twice. First on the way up, when an average built from ordinary months understates what the store is about to sell. Then on the way down, when settings raised for the peak stay raised and January inherits December's appetite. LS Central has specific machinery for both halves — a pattern tool, an event tool, and a set of supporting profiles — but the machinery only helps if the peak is run as a temporary, reversible change with the unwind scheduled before the rush starts.

Seasonality is two problems, not one

The first problem is a pattern: demand rises and falls on a rhythm visible in last year's sales — garden lines in spring, heaters in the first cold snap, the December lift across half the store. Nobody schedules these; they have to be inferred from history. The second problem is an event: a known, dated cause of extra demand — a promotion the chain itself is running, a local festival, a school term starting. Events are not in last year's pattern at the right size, and some are not in it at all. LS Central gives each problem its own tool, and using one tool for both jobs is the classic seasonal error: pattern data forced to carry a one-off promotion overstates next year, and event entries typed in to mimic a whole season are unmaintainable by the second week.

Both tools feed the same place: the Average Usage calculation behind LS automatic replenishment, where the suggested quantity is average daily sale times the coverage shortfall times the Forward Sales Forecast Factor. Native Business Central planning, for contrast, has no equivalent forward profile in its standard replenishment parameters — a BC-only planner handles seasonality by adjusting levels and forecasts manually, which is worth knowing before expecting worksheet parity with an LS store.

The pattern tool: Forward Sales Profile

The Forward Sales Profile defines a comparison period. For that period the system calculates the average sales before the comparison date and the average sales after it, compares the two, and expresses the change as the Forward Factor — total post-period sales divided by total pre-period sales. A factor above 1 means the pattern rose after that date last year; below 1, it fell. The factor is then applied to today's forecast on one explicit assumption: the seasonal pattern will appear again in the current period. Separate profiles exist for store and warehouse — the Store Forward Sales Profile applies when a journal replenishes stores, the Warehouse profile when it replenishes the warehouse — and the corresponding field must be filled in or no factor is calculated at all. The profile's filters (division, item category, retail product group, location) decide which items get the seasonal treatment, so grouping discipline decides whether the factor lands on the seasonal range or leaks across the whole catalogue.

Two supporting settings decide whether the factor can be trusted. The Replenishment Calendar handles peaks that move: for an event like Easter, whose date cannot be expressed as a fixed date formula, the calendar lets the calculation substitute the correct dates instead of comparing against the wrong week last year. And the history itself must be cleaned before it is compared: Sales History Adjustment exists to smooth sales peaks caused by one-time events, and the out-of-stock calculation excludes days with no stock on hand from the average — a store that sold out by mid-December last year did not experience low December demand, and a factor built on its truncated sales will under-plan this year's peak by exactly the amount it failed to sell.

The base rate the factor multiplies deserves the same care. The Replenishment Sales Profile defines which past periods the average daily sales come from, per item, variant, and location, and its lines can carry weights, so a recent period counts for more than an older one. Weighting recent sales higher helps a range that is trending; weighting last year's same season into the base helps a stable seasonal line. What does not help is leaving the profile untouched for years: the base and the factor are both history, and stale history is a decision to plan this peak from an old store's behaviour. Where a statistical engine is genuinely warranted, LS Forecast is the step up — a cloud-based forecasting engine using techniques such as ARIMA and Seasonal ARIMA with a best-fit approach, daily or weekly forecast granularity, safety stock derived from sales volatility, and a quality rating per forecast. It is the heavy option, and most stores' peaks are handled well by the profile machinery before an engine is needed.

The event tool: Planned Sales Demand

Planned Sales Demand is where known future demand is stated outright. It is available for items on the Average Usage and Manual Estimate calculation types, reached from the Retail Item Card through Replenishment Control Data. Each line carries an item, a location, a date, and one of three Planned Demand Types. Substitute Quantity replaces the base demand value for that date, governed by a substitute rule: always use the planned demand, or keep the base value when it is higher, or when it is lower. Additional Quantity (to Forecast) adds a stated amount on top of the base. Additional % Factor (to Forecast) adds a percentage of the base — and if a substitute line exists for the same item, location, and date, the percentage is calculated on the substituted value, because substitution takes priority. Only one Substitute Quantity line may exist per item, location, and date combination, however many additional lines sit alongside it.

Lines can be typed one at a time, bulk-inserted or updated through reports, or generated from the sources that already know about the event: a Retail Sales Budget, a Discount Offer or Multibuy promotion, or the Weekly Menu Planner. Events themselves are set up as Replen. Planned Events, linked to a source type of Budget, Discount, Menu Planner, or Manual, and an event must be enabled before it can be used. One documented trap deserves emphasis: the system performs no validation that an event's dates overlap its linked source's dates. A promotion entered against the wrong week will be planned against the wrong week, confidently. Date-checking events is a human step in the procedure, not a system guarantee.

The supporting settings: cover, caps, and lead time

Seasonal demand multiplied by ordinary cover still produces ordinary stock. The cover settings — Store Stock Cover Reqd (Days), its warehouse counterpart, or a Coverage Days Profile that adds inbound handling time and a coverage buffer — decide how many days of the inflated rate the store holds. Raising cover is the blunt instrument: it lifts everything, including the lines that will not move. The caps matter as much: Maximum Inventory will trim a seasonal suggestion back to the ceiling, and a reorder point will floor a small one, so both need a deliberate peak review rather than discovery mid-season — the level-setting logic is covered in the reorder point and safety stock guide. Lead time is the quiet constraint: a seasonal calculation that runs inside the vendor's lead time is a wish, not a plan, so the pre-season run has to happen early enough for purchase orders to land before the pattern turns.

Planning the peak: a phased procedure

1. Clean last year's history first (pre-season). Apply Sales History Adjustments to one-off peaks that should not repeat, confirm out-of-stock days are being excluded, and check the sales profile periods and weights still reflect how the range sells now. A factor is only as honest as the history it compares.
2. Assign the pattern tool (pre-season). Set the Store and Warehouse Forward Sales Profiles for the seasonal ranges — by division, category, or product group, not chain-wide — and set up Replenishment Calendar entries for moving-date events.
3. Enter the events (pre-season). Create and enable the planned events, generate or enter Planned Sales Demand lines from the budget or the promotion itself, choose substitute versus additional deliberately, and verify every event's dates against its source by eye.
4. Review cover and caps (pre-season). Raise cover days only where the peak justifies it, lift Maximum Inventory ceilings that would trim the seasonal build, and run the first seasonal journal early enough to beat vendor lead times.
5. Work the sell-through, not the plan (in-season). In-season replenishment should follow what is actually selling: protect the winners, stop feeding the losers, and use transfers between stores to correct a first allocation that put the stock in the wrong place. Do not raise the factor mid-peak to chase a good week — that is how a peak plan becomes next year's dirty history.
6. Schedule the exits (before the peak ends). Decide the markdown and clearance path for leftover seasonal stock while it still has selling weeks left, not after it has become carryover competing for space with the next season's buy.
7. Unwind on a date (end of season). Disable the events, restore normal cover days and maximum levels, and return forward profiles to their off-season state. Then run the post-season review: turnover, how often items stocked out, and what the leftover stock cost to hold — those three numbers are the feedback that makes next year's factor honest.

What success looks like

A good peak is unremarkable in both directions: the seasonal lines are in stock through the high weeks without emergency orders, the non-seasonal lines never noticed the factor, and within a few weeks of the peak ending, cover, caps, and profiles read exactly as they did before it started. The leftover pile is small, deliberate, and already priced to move. A bad peak leaves fingerprints — a factor still rescaling forecasts in the quiet month after, maximums still lifted, and a clearance corner full of stock the plan swore would sell. Seasonality handled well is mostly the discipline of the unwind.

FAQ

Should a promotion use the Forward Factor or Planned Sales Demand? Planned Sales Demand. The factor infers a recurring pattern from history; a promotion is a known event with known dates. Entering the event also keeps last year's history clean of a spike that was caused, not seasonal.

Why did the factor understate the peak? Check the history it compared: if the store stocked out during last year's peak and out-of-stock days were not excluded, the "pattern" it learned is the truncated sales, not the demand. Check also that the store profile — not only the warehouse profile — is the one filled in for store journals.

When should LS Forecast replace profiles? When the range is large, the patterns interact, and someone will actually read the forecast quality ratings and act on them. For a defined seasonal range with a readable history, the Forward Sales Profile plus Planned Sales Demand is the proportionate tool — and both halves of it are reversible, which at the end of a season is the feature that matters most.