Reviewed and updated June 2026 — formulas and PrestaShop stock settings checked against versions 1.7, 8 and 9.

Here is a scenario that plays out in PrestaShop stores every week. You open Catalog → Stocks, and your best-selling product shows 3 units left. Your supplier takes 14 days to deliver. You move roughly 2 units a day. The arithmetic is brutal and obvious: you sell out in under two days, the replacement stock lands two weeks later, and you have just booked twelve days of zero sales on your top product. The frustrating part is that none of it was a surprise — the data to predict it was sitting in your back office the whole time. A reorder point is simply the number that turns "we ran out again" into "the new stock arrived the week before we needed it."

This guide is about one specific decision: at what stock level do you place the next supplier order, and how you wire that threshold into PrestaShop so it tells you instead of you remembering to check. It is the planning layer that sits underneath every other inventory decision — whether you hide out-of-stock products, whether you allow backorders, how you structure your catalogue. Those are separate questions with their own answers, linked where they belong below; here we stay on the formula and the back-office settings that enforce it.

The reorder point formula

The most useful inventory number you can calculate is the reorder point — the stock level at which you trigger a new supplier order:

Reorder Point = (Average Daily Sales × Lead Time) + Safety Stock

Worked example:

  • Average daily sales: 5 units
  • Supplier lead time: 10 days
  • Safety stock: 15 units
  • Reorder Point = (5 × 10) + 15 = 65 units

When on-hand quantity drops to 65, you order. The 50 units (5 × 10) cover expected sales while you wait for delivery; the 15-unit safety buffer absorbs a busy week or a late shipment. So what does that buy you? The supplier order goes out at the moment that leaves you with a thin-but-positive buffer when the truck arrives — not weeks early (capital frozen on the shelf) and not three days too late (the twelve-days-of-zero-sales scenario above).

The three inputs are not guesses. Two of them — average daily sales and your real lead time — already live in your PrestaShop database, and the next sections are about pulling them out accurately.

Calculating average daily sales from PrestaShop data

Use at least 30 days of sales history, and 90 days if you have it. Shorter windows are too volatile — one good week skews the average upward and you over-order. PrestaShop gives you this without a spreadsheet: Stats → Best-selling products lets you set a date range and shows total quantity sold per product over that period. Divide units sold by the number of days in the range and you have your average daily sales.

Two refinements matter for the formula to be honest:

  • Exclude the days a product was actually out of stock. If a product sat at zero for eight days of a 30-day window, dividing by 30 understates true demand and you will set the reorder point too low — guaranteeing the next stockout. Divide by the days it was available, not the calendar days.
  • Handle seasonality with last year, not last month. For a seasonal line, take the same period from the prior year and adjust for growth. Sold 300 units of a product last June and the business is up 20%? Plan for roughly 360 this June. A 90-day trailing average would miss the spike entirely.

If you run combinations (sizes, colours), pull the numbers per combination, not per product — a "medium" that sells daily and an "XXL" that sells monthly need different reorder points even though they share a product page. PrestaShop tracks stock per combination, and so should your planning.

If you'd rather pull the raw numbers yourself — for instance to feed a spreadsheet that calculates reorder points across many products at once — a read-only query in Advanced Parameters → Database → SQL Manager gives you units sold per product over a window. This sums quantities from validated orders in the last 90 days:

SELECT od.product_id,
       od.product_name,
       SUM(od.product_quantity) AS units_sold
FROM ps_order_detail od
JOIN ps_orders o
  ON o.id_order = od.id_order
WHERE o.valid = 1
  AND o.date_add >= DATE_SUB(NOW(), INTERVAL 90 DAY)
GROUP BY od.product_id, od.product_name
ORDER BY units_sold DESC;

Divide each units_sold by 90 (or by the days the product was actually available, per the refinement above) for average daily sales. The query only reads — it never changes data. o.valid = 1 keeps it to orders PrestaShop counts as real sales, so cancelled and payment-error rows don't inflate demand. For combination-level detail, group by od.product_attribute_id as well. For most stores, though, Stats → Best-selling products with a date range is the no-SQL path to the same numbers.

Safety stock: how much buffer is enough

Safety stock covers the two things the average can't see: demand spikes and supplier slippage.

  • Demand variability: the average is 5/day, but real days run from 3 to 8. The buffer covers the above-average days that occur while you are waiting for restock.
  • Supply variability: the supplier quotes 10 days and delivers in 14 more often than they'd admit. The buffer covers the gap between quoted and actual lead time.

A practical formula for small stores:

Safety Stock = (Maximum Daily Sales − Average Daily Sales) × Maximum Lead Time

Worked example:

  • Maximum daily sales (busiest realistic day): 8 units
  • Average daily sales: 5 units
  • Maximum lead time (worst observed case): 14 days
  • Safety Stock = (8 − 5) × 14 = 42 units

That's deliberately conservative — it's sized for the bad-day-meets-late-delivery case. For non-critical products or a tight cash position, scale it down. The trade-off never goes away: more safety stock means fewer stockouts but more capital sitting idle; less safety stock frees the cash but raises the odds of running dry. That is exactly why the next section says not to apply the same buffer to every product.

ABC analysis: spend your attention where the revenue is

You might carry hundreds of SKUs, but they don't deserve equal effort. ABC analysis sorts them by revenue contribution so you invest precision where a stockout actually hurts:

ClassShare of catalogueShare of revenue (typical)MonitoringSafety stock
ATop ~20%60–80%Check daily; precise reorder pointGenerous — a stockout here is expensive
BNext ~30%~15–25%WeeklyModerate
CBottom ~50%Single digitsMonthlyMinimal — a week out of stock barely registers

The revenue split follows the usual Pareto shape; treat the percentages as directional and confirm yours from Stats → Best-selling products sorted by sales value. The point stands either way: perfect reorder planning for a product that sells twice a month is wasted effort next to getting your A-list thresholds right. Calculate full reorder points and safety stock for A products, approximate for B, and for C products a simple "reorder when it hits this round number" is enough.

Wiring reorder points into the PrestaShop back office

Purchase Orders panel with search and filter controls, a New Order button, and a table listing seven purchase orders by supplier, items, warehouse and workflow
The list shows seven purchase orders with supplier, item count, expected date, warehouse, workflow, status and total columns, plus View and action buttons per row.

A reorder point you have to remember to check is a reorder point you will eventually forget. PrestaShop can watch the threshold for you. On each product, open the Quantities tab and you'll find two settings that turn your calculated number into an automatic signal:

  • Minimum quantity for sale — how low stock can go before the product stops being orderable. This is your floor, not your reorder trigger.
  • Low stock alert (the "Receive a notification by email" / low-stock-level field) — set this to your reorder point, not to 1 or 2, and enable the email option. When on-hand quantity crosses it, PrestaShop sends a low-stock notification email. The recipient is the merchant/employee notification address, not a Customer Settings field — verify where that mail is routed in your version's employee or mail-alert configuration. That email is your "place the supplier order today" trigger.

The mechanism behind the scenes: stock for each product or combination lives in the ps_stock_available table and is managed through the StockAvailable class. Every order decrements it and fires the actionUpdateQuantity hook, which is what the low-stock check rides on. You don't need to touch any of that — but it's why setting the alert field per combination matters: each combination has its own row and its own threshold.

One platform decision shapes all of this. In modern PrestaShop, stock management lives under Shop Parameters → Product Settings, controlled by the PS_STOCK_MANAGEMENT configuration value. Legacy PrestaShop 1.6 additionally exposed Advanced Stock Management (multi-warehouse, physical vs. usable quantities, supplier stock movements in ps_stock), gated by the PS_ADVANCED_STOCK_MANAGEMENT value — a 1.6-era concept that newer versions no longer surface as a normal setting. For a single-location small store, simple stock plus the low-stock alert is the right tool — that legacy ASM machinery added real overhead and was built for warehouse operations, not for a shop reordering from one supplier.

If you've outgrown native low-stock emails — you want one screen listing every product below its reorder point, with its supplier and suggested order quantity, rather than chasing individual emails — that's the moment a dedicated stock dashboard earns its keep. We cover the wider "when the back office isn't enough" threshold in inventory management for small online stores, and the mypresta.rocks module catalogue includes tools that surface reorder-point breaches across the whole catalogue in one view rather than per-product alerts.

How much to order each time

The reorder point tells you when; order quantity is how much. Order too often and you waste admin time and per-shipment costs; order too much and you freeze capital and warehouse space. The textbook answer is Economic Order Quantity:

EOQ = √(2 × Annual Demand × Order Cost / Holding Cost per Unit)

  • Annual Demand: units sold per year (a full year of Stats → Best-selling products).
  • Order Cost: the fixed cost of placing one order — shipping, handling, your admin time.
  • Holding Cost: the annual cost to store one unit — space, insurance, and the opportunity cost of tied-up capital, commonly 15–25% of the unit's cost.

Honestly, most small stores don't need the square root. A workable rule: order enough to cover demand until your next natural reorder, plus your safety stock. If you reorder monthly and sell 150 units a month, order 150 plus the buffer that keeps you at your target safety level. Reach for EOQ only when order costs or holding costs are high enough that the frequency genuinely changes your margins.

Your formulas are only as good as your lead-time data

The single most common reason a correct reorder point still ends in a stockout: the lead time plugged into it is the number the supplier quoted, not the number they actually deliver. Track real lead times and feed the real numbers in:

  • Log the gap between the day you place each order and the day stock actually lands — in legacy 1.6 Advanced Stock Management, Stock → Stock movements timestamps receipts; for a modern simple-stock shop, track supplier lead times manually in a column in your reorder spreadsheet.
  • Use the worst observed lead time, not the average, for your A products' safety-stock calculation. The buffer exists for the bad case.
  • Keep a backup supplier for A products and order on a regular cadence — suppliers prioritise predictable customers, which quietly shortens your real lead time.

What stockouts actually cost — and the decisions that follow

Merchants consistently underprice running out of stock. The lost sale is only the visible part:

  • Lost sale: the customer who wanted to buy and couldn't.
  • Lost customer: they try a competitor and may not come back.
  • Wasted ad spend: every click on an ad for an out-of-stock product is money burned.
  • Catalogue and indexing churn: depending on how you handle out-of-stock products, pages can drop in and out of your sitemap.

Add up the daily revenue your top five products generate, and that figure is what a missing reorder system costs you per stockout day. For most stores it dwarfs the cost of carrying a little more safety stock — which is the whole argument for setting these thresholds and letting PrestaShop watch them.

A good reorder point prevents most stockouts, but not all of them, and it doesn't decide what your storefront does when stock does hit zero. Those are deliberately separate decisions:

  • What customers see at zero stock. Hide the product, or keep it visible with availability text? Both are defensible, and the right call depends on your catalogue — the full argument is in out of stock: to hide or not to hide.
  • Selling through the gap. If you can take orders against incoming stock, backorders and pre-orders turn a stockout into a delayed sale instead of a lost one — see pre-orders and backorders in PrestaShop.
  • Reordering at scale. Once you're managing hundreds of SKUs, you'll want to bulk-export stock and sales data to crunch reorder points outside the back office — CSV exports for orders and invoices and product import and export cover getting the data in and out.

Frequently asked questions

What is the reorder point formula?

Reorder Point = (Average Daily Sales × Lead Time) + Safety Stock. If you sell 5 units a day, your supplier takes 10 days, and you hold a 15-unit buffer, you reorder when stock hits (5 × 10) + 15 = 65 units. The first 50 cover expected sales while you wait; the 15 absorb a busy week or a late shipment.

How do I calculate average daily sales in PrestaShop?

Use Stats → Best-selling products with a 30- to 90-day date range, then divide units sold by the days in the range — but divide by the days the product was available, not the calendar days, or a past stockout will understate true demand. For a per-combination or bulk view, the read-only SQL query above pulls the same numbers straight from the order tables.

Where do I set the reorder trigger so PrestaShop reminds me?

On each product's Quantities tab, set the low-stock-level field to your calculated reorder point (not 1 or 2) and enable the email notification. When on-hand quantity crosses it, PrestaShop emails the merchant notification address — that email is your "place the supplier order today" trigger. Set it per combination, since each combination has its own row and threshold.

How much safety stock should I carry?

A workable formula for small stores: Safety Stock = (Maximum Daily Sales − Average Daily Sales) × Maximum Lead Time. Use the worst observed lead time, not the average — the buffer exists for the bad-day-meets-late-delivery case. Carry generous safety stock on your A-list bestsellers and minimal on the long tail; a week out of stock on a €2 accessory barely registers.

Does the low-stock email handle multiple warehouses?

No — native stock and its low-stock alert assume one pool. The moment your stock lives in more than one location, a single threshold stops describing reality. Per-location reorder points (the office running dry doesn't mean the warehouse is) are part of Warehouse Revolution.

Inventory planning doesn't have to be complicated. Reorder points for your A products, the low-stock alert field set to those points so PrestaShop emails you instead of you remembering to look, real lead-time numbers, and a weekly glance at Catalog → Stocks — that's enough to run most small stores without a single emergency reorder. The formulas are simple arithmetic. The win comes from putting the threshold somewhere the system will enforce it, so the discipline doesn't depend on your memory.

Share this post:
David Miller

David Miller

Founder, mypresta.rocks

David Miller is a PrestaShop specialist with over a decade of hands-on experience and the founder of mypresta.rocks, a software studio in Tychy, Poland. He builds and maintains a catalogue of 152 PrestaShop modules — including 21 "Revolution" suites spanning SEO, checkout, security, performance, marketing, search, support, and warehouse operations — that improve real stores every day, all tested against PrestaShop 1.7.8, 8.x, and 9.x. He also acts as caretaker for production stores turning over millions in annual sales, so his work is judged on live revenue, not demos. His experience runs the full breadth of ecommerce — performance, security, SEO, and marketing — and reaches beyond PrestaShop to WooCommerce, Shopify, and custom-built systems. On the blog he writes about the code-aware side of PrestaShop: what the platform really does under the hood, what breaks in production, and which fixes hold up.

Enjoyed this article?

Get our latest tips, guides and module updates delivered to your inbox.

Comments

No comments yet. Be the first!

Be the first to ask a question or share useful feedback.

Loading...
Back to top