Rytm: demand forecasting and stock replenishment for warehouse and store networks

What problems it solves

• Stockouts of fast movers. The system sees which items will run out before the next delivery arrives and shows the lost revenue while the shelf is still not empty.
• Cash frozen in excess stock. A list of items and locations holding more than 90 days of sales, with the amount at purchase price.
• Imbalance between warehouses. One location has too much, another too little. The system suggests a transfer before a new purchase.
• Ordering by gut feeling. Quantities come from the forecast, lead time, safety stock, minimum order and pack size. Orders are already grouped by supplier and warehouse.
• A forecast nobody trusts. Accuracy and systematic bias are visible for every item, and the forecast model is chosen by testing on history, not by opinion.
• A second set of records in Excel. Products, stock, sales and purchases come from the ERP; decisions go back there as documents in one click.

Who it is for

Distribution, retail chains, online stores with their own warehouses, manufacturing that buys components. The system pays off where there are a hundred or more items, several storage locations and lead times measured in weeks: that is when an ordering mistake costs the most.

What you see right after sign-in

Eight numbers that tell a manager the state of stock in a minute. In the demo company (the "Mobilus" chain: 14 phone models, 5 locations):

Key algorithms

Below is what usually hides in a black box. Every decision of the system breaks down into these steps and can be checked by hand.

1. Data preparation: demand, not sales

Sales and stock come by day, for every item and every location. Returns are not counted as demand. The main correction is out-of-stock days. If the item was not on the shelf, zero sales do not mean zero demand. When the item was available n of N days in a month (and at least a third of the month), monthly demand is restated as sales × N / n.

Without this correction every stockout lowers the next forecast, the system orders less, and the stockout repeats. This is the most common reason a spreadsheet forecast fails.

2. ABC/XYZ: importance and predictability

• ABC by revenue over 12 full months: items sorted in descending order, A takes the first 80 % of revenue, B the next 15 %, C the remaining 5 %.
• XYZ by the coefficient of variation of monthly demand (standard deviation / mean): X below 10 %, Y 10 to 25 %, Z above 25 %.
• Thresholds are configurable and recalculated instantly.

The segment is not a report for its own sake: it drives the safety stock. The more important the item and the less predictable its demand, the more days of stock the system keeps beyond the lead time.

In the demo, 3 AY models bring 52 % of revenue and 2 AZ models another 36 %. Eight of the fourteen items together bring less than 10 %: they are not worth tying up cash.

3. Forecast: testing on history picks the model

A 12-month forecast is built for every item with three models:

• 3-month moving average: reacts quickly to change;
• 6-month moving average: robust to noise;
• trend × seasonality (with 15+ months of history): a linear trend is fitted on the deseasonalised series, and calendar-month seasonal indices are normalised to one. Trend and indices refine each other over several passes, otherwise a partial year in the history (a December peak at one edge only) skews the slope. The trend is damped: a year ahead the forecast level stays within 0.5–1.6 of the current one.

A backtest decides which model to use. The system holds out the last 6 months, forecasts them with each model from earlier data and compares with actuals. The model with the lowest WAPE wins. A demo example, iPhone 11 with clear September and December peaks:

The forecast is made per item and split across locations by their share of demand over the last six months. Item × location series are too noisy for their own seasonality, while the network total gives a stable shape.

4. Forecast accuracy

• WAPE = Σ|forecast − actual| / Σ actual: average error as a share of sales;
• Accuracy = 100 % − WAPE: green from 85 %, yellow 70–85 %, red below 70 %;
• BIAS = Σ(forecast − actual) / Σ actual: systematic over-forecasting (plus) or under-forecasting (minus);
• MAE in units; the evaluation window matches the backtest window.

Company accuracy is revenue-weighted: an error on an expensive fast mover matters more than on a cheap one. In the demo it is 89 %.

5. Plan: forecast, year target and manual edits

• Year target (top-down): management sets a 12-month sales amount, the system splits it across items by their revenue share and across months by the forecast shape.
• Manual edit of any month for any item with a click in the cell. Manual values override the calculation and are highlighted.
• Every recalculation is saved as a plan version; the last five are kept for comparison.

6. How much and when to order

The calculation runs for every item × location pair:

d   = plan for the next ~45 days / number of days × location share (daily demand)
L   = production time + delivery time                                 (lead time, days)
SS  = d × safety days of the ABC/XYZ segment                           (safety stock)
ROP = d × L + SS                                                       (reorder point)
P   = on hand + incoming (open purchases and transfers in the ERP)     (position)
T   = d × (L + order cycle + safety days)                              (target cover)

stockout  if P − d × L < 0           (runs out before the delivery arrives)
buy       if P ≤ ROP
excess    if P / d > 90 days
order qty = max(T − P, MOQ), rounded up to the pack size, capped by max order
lost sales = days out of stock × d × selling price
frozen cash = (P − T) × purchase price

A worked example from the demo. Xiaomi Redmi Note 9 Pro, "Mobilus" store, segment AY:

These exact numbers are what the user sees in the item card: no decision has to be taken on faith.

7. Transfers before purchases

For every item the system finds donor locations (surplus with live demand) and receivers (stockouts first, then "buy"). A receiver gets min(needed to target, donor surplus) from the largest donor. If the transfer fully covers the need, the purchase is cancelled; if partly, it is reduced. In the demo 85 phones are redistributed this way instead of being bought again while they sit in a neighbouring warehouse.

8. Speed and freshness

ERP data is pulled every 15 minutes; recalculation runs after each sync and after every parameter change. A full demo calculation (14 items × 5 locations, 25 months of daily history) takes 0.1–0.2 seconds; the work grows linearly with the number of item × location pairs.

ERP integration

Rytm keeps no second set of records. Catalogues, stock, sales and purchases live in the ERP (our Forma in the demo); Rytm reads them and sends decisions back as documents:

• data export: products, warehouses, suppliers, stock, daily sales, open purchases and transfers (counted as incoming);
• draft purchase: supplier, warehouse, item lines with quantity and price, in one click from the order card;
• draft transfer between warehouses;
• sign-in without separate passwords: logged in to the ERP means logged in to Rytm (one-time signed token).

All requests are signed with a shared secret (HMAC-SHA256). Documents are created by the ERP's own mechanisms, so payment, delivery and receipt follow the usual routine and Rytm only reads their state. For another accounting system (1C/BAS, Odoo, an in-house ERP) the same three operations are implemented.

Interface

Six screens: decisions, products, plan, matrix, documents, settings. Minimal text: colour shows the state, numbers explain the decision, key actions take one click. It works the same on a phone with the navigation at the bottom.

How we roll it out

Timeline and cost are estimated after the first stage: they depend on the ERP, the number of items and the quality of history. The system runs in your infrastructure or ours; source code is handed over under the contract.

What is real and what is demo

• Real: all algorithms and calculations on the server, sign-in through the ERP, catalogues and stock from the ERP demo account, documents are actually created in the ERP.
• Demo: 25 months of sales history are generated (the demo account has none); the company "Mobilus" is fictional.

See the system: frontend-logistic2.ingello.com (opens without sign-in in view mode). Presentation: landing-logistic2.ingello.com. Discuss a rollout: talk to an architect.

A similar solution: platFORMA - an advanced system for your company's departments.