LS replenishment planning basics: how LS Central decides what each store needs

Inventory & replenishment · 10 min read

Every replenishment journal line answers one question: how much of this item does this store need, on top of what it already has or already has coming? LS Central answers it with a short chain of decisions — a calculation type, a sales rate, a number of cover days, and an honest count of stock in motion. When a suggestion looks wrong, one link in that chain is wrong. This guide walks the chain in order, so the wrong link is findable.

What replenishment is deciding, in plain terms

LS Replenishment exists to get the right items to the right place at the right time, and it splits into two families. In automatic replenishment, a calculation engine works out the quantities and suggests Purchase Orders and Transfer Orders in replenishment journals. In manual replenishment, a buyer actively initiates the orders instead: purchase orders directly or through Allocation Plans, transfers pushed to stores with Buyer's Push under Allocation Rules, Stock Recall to pull stock back to the warehouse at the end of a product's life, and Stock Requests that a store sends to the central purchase department for approval. Manual is the push principle, suited to one-time items and very short life cycles. Automatic is for reoccurring items — the everyday sellers a store must never run out of — and it is the automatic side this guide explains.

Do not confuse either family with native Business Central planning. Business Central has its own planning engine: an item needs a reordering policy on the Item Card (Fixed Reorder Qty., Maximum Qty., Order, or Lot-for-Lot) before planning will touch it, and its suggestions land in the planning or requisition worksheets. LS replenishment is a separate system with its own setup on the item's Replenishment Control Data and its own journals. A store running LS Central normally lives on the LS calculation; the BC worksheet is not a second opinion on the same number, it is a different engine answering a different setup.

The calculation types, compared

The first decision is the Replenishment Calculation Type on the item's replenishment data. It decides where the demand signal comes from:

Two supporting fields modify whichever type is chosen. If the calculated suggested quantity is smaller than the Reorder Point, the system raises it up to the reorder point — the documented example suggests 8, the reorder point is 10, and the system quantity becomes 10. If Maximum Inventory is filled in, it caps the result: under Stock Levels with a maximum of 20, a reorder point of 10, and 8 on hand, the system reorders 12; under Average Usage a calculated demand of 30 with the same maximum is still cut back to an order of 12, because stock after receipt cannot exceed 20. A maximum of 0 switches the cap off. Order multiples then round the journal quantity: purchase and transfer quantities are always a multiple of the item's Purchase Order Multiple or Transfer Multiple, using the rounding rules on the Replen. Multiple Rounding page.

How the suggested quantity is built

For Average Usage — the type most stores run — the chain has four links.

1. Average Daily Sale. The system takes the item's sales from Item Ledger Entries over the period defined in the Replenishment Sales Profile, corrected by any Sales History Adjustments, and divides by the days in the period minus the out-of-stock days. In the documented formula: Average Daily Sale = −Quantity / (No. of Days − No. of Out of Stock Days). The out-of-stock exclusion matters: a week spent with an empty shelf is not a week of zero demand, and counting it as one drags the average down and understates every future suggestion. Where a sales profile has several periods, each period's weight adjusts its contribution, so recent sales can count for more than older sales.

2. Required stock cover. The forecast is multiplied by the number of days the stock is supposed to cover. That figure comes either from a Coverage Days Profile — which builds it from the days until the next calculation, plus inbound handling time and a coverage buffer, minus store closing days — or directly from the Store Stock Cover Reqd (Days) or Wareh Stock Cover Reqd (Days) field. The arithmetic is deliberately simple: an average daily sale of 5 with 10 cover days means the store should hold 50.

3. The forward factor. A Forward Sales Profile compares last year's sales before and after a comparison date and turns the change into a factor — total post-period sales divided by total pre-period sales. A factor of 1.1 expects the coming period to run about a tenth hotter than the base rate. Seasonality gets its own treatment in the seasonality guide; here it is enough to know the factor multiplies the cover calculation, it does not replace it.

4. Effective inventory. Finally the system subtracts what the store effectively already has. The documented formula is: Inventory + quantity on purchase orders − purchase returns − quantity on sales orders + transfers in − transfers out + assembly header quantity − assembly line quantity. Which document types count is set in the Effective Inventory setup, where each type can be set to Include, Exclude, or Coverage (counted only within the defined coverage and historical windows). Put together, the suggested quantity is: Average Daily Sale × Required Stock Cover Days × Forward Sales Forecast Factor − Effective Inventory — or minus Projected Effective Inventory when Lead Time Calculation is enabled, so stock arriving during the vendor or sourcing-location lead time is not ordered twice. A result below zero is set to zero: no demand, no line. Known future peaks enter through Planned Sales Demand, which adjusts the calculation for the days it covers instead of letting the plain average speak for an event it knows nothing about.

The calculation lands in journals, in four steps: optionally calculate out-of-stock days, build the Replenishment Item Quantity records, add and calculate the journal lines, then post the journal to create the actual orders. The Purchase Replenishment Journal creates purchase orders for stores and warehouses — with a matching transfer order when cross-docking — and the Transfer Replenishment Journal creates transfer orders to move stock from the warehouse to the stores. Nothing is ordered until the journal is posted, which is what makes the review step below possible.

Effective inventory: what counts and what does not

Most "the system ordered nonsense" complaints trace back here, and most are really data complaints. Effective inventory is only as good as the records feeding it. A purchase order that was received but never posted still counts as incoming. A transfer that left one store and was never received at the other sits in the formula as if it were stock. A shelf count that drifted months ago makes the opening inventory figure fiction. The standing principle is unglamorous: clean data is the most useful thing anyone can give a replenishment system, and unknown or unverified quantities should not be entered until they are cleaned up, because every suggestion downstream inherits the error. Before blaming the calculation type, check the inputs: inventory accuracy, open orders that should be closed, and whether out-of-stock days are actually being calculated — an item that was out of stock for half the profile period will be under-ordered by design until that exclusion is switched on.

Two smaller settings decide which lines appear at all. An item flagged Exclude from Replenishment is skipped entirely — the right switch for a paused line, and a confusing bug when set by accident. And the vendor on a purchase suggestion is resolved in a fixed order: the vendor on the replenishment data record first, then the stockkeeping unit, then the item card. The Purch. Order Delivery setting — To Warehouse or To Store — decides where that purchase order lands, which changes which journal picks the item up.

A first-run procedure before trusting a journal

Run this once per item group before the first live journal, and again after any setup change. It suits a how-to check because each step has a visible result.

1. Confirm the calculation type per item. Open the item's Replenishment Control Data from the Retail Item Card and check the type matches the item's life: Average Usage for established sellers, Manual Estimate only while there is genuinely no history, Stock Levels for display-driven slow movers.
2. Check the sales profile period. The period must be long enough to be stable and recent enough to be relevant, and out-of-stock calculation must be active for items with known stock-outs, or the average daily sale starts life understated.
3. Set cover days deliberately. Store cover, warehouse cover, and any coverage profile should reflect how often the journal actually runs plus handling time — not a round number copied from another store.
4. Audit effective inventory inputs. Close or correct stale open purchase, sales, and transfer documents for the test items, and verify the on-hand figure against a physical count for at least a sample.
5. Run the calculation for a small scope first. One store, one item group. Read every line: does the suggested quantity roughly equal average daily sale times cover days, adjusted by the forward factor, minus effective inventory?
6. Spot-check one line by hand. Recompute it from the item ledger and the open documents. If the hand calculation and the journal agree, the chain is set up correctly; if they disagree, the disagreement names the broken link.
7. Only then widen the scope and post. Post the journal, and confirm the purchase or transfer orders it created match the reviewed lines.

What success looks like

A correct first run is boring: every suggested quantity can be re-derived by hand from sales history, cover days, and effective inventory; no line appears for an excluded item; no line duplicates stock already on a purchase order or in transit; and the posted orders match the reviewed journal exactly. When a line surprises, it surprises by a traceable amount — a forward factor, a multiple rounding, a maximum cap — never by an unexplained leap. Choosing between types stays a judgement call: history-based calculation for anything with a sales pattern, estimates only until history exists, fixed levels where the shelf itself is the requirement, and manual push for the one-off buys no calculation should pretend to predict.

FAQ

Why did the journal suggest zero for a selling item? Either effective inventory already covers the calculated need — the formula floors at zero — or the item is excluded from replenishment, or its sales history sits outside the sales profile period.

Is the LS journal the same as the Business Central planning worksheet? No. They are separate engines with separate setup: BC planning needs a reordering policy on the Item Card and works through its worksheets; LS works from Replenishment Control Data into purchase and transfer replenishment journals.

Where do known events — a promotion, a local festival — go? Into Planned Sales Demand, available for Average Usage and Manual Estimate items. The event must be enabled before it can be used, and its demand adjusts the calculation for the covered days instead of distorting the sales history.