PrestaShop inventory: stock, reordering, variants and fulfilment

What we would do

We would first establish who owns each stock balance, then use native stock until a specific requirement needs more. The route depends on your existing PrestaShop version, modules, integrations, theme, product and combination data, markets and the team receiving and dispatching goods. Keep a working ERP or warehouse system authoritative if it already manages those operations; adding another stock master creates a reconciliation problem.

Choose the route for the missing operation

If you need the routes tested against your current shop, the PrestaShop Module Selection & Fit Assessment checks the fit on a controlled copy.

Make stock-system, feed or catalogue-structure changes on a staging copy with your actual theme, modules and representative data. Isolate customer emails, supplier orders and external stock writes so rehearsals cannot change live operations. Rehearse sales, receipts, cancellations, returns and interrupted synchronisation, then plan the live switch with an agreed reconciliation point, a reversible configuration and someone responsible for exceptions.

Use the right stock quantities

Use PrestaShop as your stock record when it controls the inventory you sell. If an ERP or warehouse system is authoritative, define how it updates PrestaShop and how orders return to that system. Parallel manual edits create conflicting balances.

The storefront quantity is not a record of when a parcel physically leaves your shelf. Shipping states affect reserved and physical calculations. Cancellation, refunds and stock reinjection have separate effects. Test those paths with your payment and order modules before relying on a balance.

Modern stock data lives in stock_available, using your configured table prefix. Product totals and combination rows can coexist. Modern simple-stock movements also use stock_mvt; in this context id_stock links to a stock_available record. Do not join every movement to the legacy warehouse stock table.

Overselling, unexplained discrepancies, missed receipts, channel disagreements and growing reconciliation work are reasons to improve your process. A tool does not replace accurate receiving, returns and physical counts.

Configure quantities, alerts and reports

1. Check stock management under Shop Parameters > Product Settings.
2. Open each product's stock section. PrestaShop 9 labels it Stocks, or Pack for packs. Earlier forms can use Quantities.
3. Set available quantity at the combination level when variants have independent stock.
4. Set minimum quantity for sale to the minimum number the customer must buy. It is not a remaining-stock floor or reorder point.
5. Set the low-stock threshold and enable its email alert. Use your calculated reorder point where appropriate.
6. Choose deny orders, allow orders or inherit the global out-of-stock default.

Use Catalog > Stocks for the native overview, low-stock highlighting and quick filter. The modern interface returned in 1.7.2; per-product thresholds and alerts followed in 1.7.3. Do not apply this workflow unchanged to 1.6.

Core checks low stock directly after its quantity update and hook dispatch. It sends alerts to employees whose profiles have stock-management read permission. Verify employee addresses, permissions and mail delivery. A mail-alert module can have separate recipient settings.

A scoped stock snapshot

This read-only example lists simple products and individual combination rows at or below 10 available units for unshared shop 1 and language 1. It excludes a combination product's aggregate row. Change the prefix and confirmed shop/language IDs for your store. Shared-stock groups require their group-scoped stock row instead of this shop condition.

SELECT sa.id_product, sa.id_product_attribute, pl.name, sa.quantity
FROM ps_stock_available sa
JOIN ps_product_lang pl
  ON pl.id_product = sa.id_product
 AND pl.id_shop = 1 AND pl.id_lang = 1
WHERE sa.id_shop = 1
  AND sa.quantity <= 10
  AND (sa.id_product_attribute > 0 OR NOT EXISTS (
    SELECT 1 FROM ps_product_attribute pa
    WHERE pa.id_product = sa.id_product
  ))
ORDER BY sa.quantity, sa.id_product, sa.id_product_attribute;

Use read-only reporting access. Read-only queries can still consume resources on a large database. Prefer the native overview for routine checks.

Calculate reorder points and order quantities

Plan per sellable SKU or combination. Record actual supplier lead time from placing the order until the goods are usable for dispatch. Modern core sales history does not provide a complete supplier purchasing and receipt history; maintain this separately or through your purchasing system. Log order placement, supplier acceptance, arrival and the point when inspection or putaway makes the goods usable. Transport time alone misses delays before dispatch and after arrival. Revisit the inputs after a supplier change or a run of late receipts.

Reorder point = average daily demand × average lead time + safety stock
Inventory position = available stock + confirmed incoming stock

Adjust for commitments not already reflected in available stock. Do not subtract reservations or backorders twice. Reordering from on-hand stock alone can duplicate an order already in transit.

For example, demand of 5 units per day, a 10-day lead time and a 15-unit buffer give a reorder point of 65 units. The first 50 cover average lead-time demand. This is a planning estimate, not a guarantee against stockouts.

Turn a threshold into a purchasing decision

In the 65-unit example, a low-stock email starts a review, not an automatic duplicate purchase. Compare demand until the next usable receipt with available stock, confirmed inbound quantities and promises already made.

Demand history and seasonality

Use a representative sales window, such as 30 or 90 days, and inspect promotions and seasonality. Where a best-selling-products statistics module is installed, its date-range report can help. Divide units sold by the days in the period for a starting daily average. Then allow for days when a stockout prevented sales and for unmet demand, using comparable in-stock periods where you can: sales alone understate demand during a stockout.

This query reports gross ordered units on currently valid orders during the last 90 days for shop 1, grouped by product and combination. It does not subtract every refund or return and is not a complete demand forecast. Check order-state policy and cancellations in your shop before using the totals.

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

If a seasonal line sold 300 units in the comparable prior period, an explicitly assumed 20% increase gives a planning case of 360 units. Validate the growth assumption against your own demand.

A worst-case safety-stock heuristic

Safety stock = maximum daily demand × maximum lead time
             - average daily demand × average lead time
Example: 8 × 14 - 5 × 10 = 62 units
Reorder point: 5 × 10 + 62 = 112 units

This assumes the selected maximum demand persists throughout the maximum lead time. It can overstate the buffer and does not assign a service probability. Review unusual peaks, cash limits, shelf life and supplier reliability.

How much to buy

For periodic ordering, set a target covering the review interval, lead time and safety stock. Subtract your inventory position to calculate the order quantity. Respect supplier pack sizes, minimum orders, storage and expiry limits.

EOQ = square root(2 × annual demand × cost per order
                  / annual holding cost per unit)

EOQ assumes a stable demand and cost model. Calculate holding costs from your storage, insurance, capital and obsolescence costs. Reorder point decides when to act; order quantity decides how much to buy.

Reconcile stock and monitor inventory

Group products by their actual revenue, margin, criticality and supply risk. Count important or error-prone items more frequently. Weekly checks for selected A items, monthly checks for B items and quarterly checks for C items are possible schedules, not fixed category percentages.

1. Pause or account for movements while counting a location.
2. Compare the count with the correct stock pool and pending receipts, reservations and dispatches.
3. Investigate receiving errors, damage, mis-picks, missing returns and unrecorded transfers.
4. Post an authorised adjustment with a reason. Keep the movement history.

Review ageing stock using intervals that suit your products. The 90-, 180- and 365-day points can be review prompts, but seasonal goods and short-life stock need different rules. Compare markdown recovery with carrying cost before discounting, bundling, donating or writing off stock.

Trace a discrepancy before correcting it

Match the product reference, combination, shop or shared stock group and comparison time before comparing reports. An available balance and a shelf count can differ legitimately because of reservations. Trace the relevant order, import, receipt, return or adjustment in the owning system, including which employee or integration made the change. If an import repeatedly overwrites the same correction, investigate its mapping and ownership rather than recounting the shelf again.

For multi-channel sales, choose a master stock system and document update direction, frequency, retries and conflict handling. Conservative channel allocations can reduce exposure during update delays, but they cannot guarantee that overselling never occurs.

For selectable-field, filtered exports, use the Orders CSV List Exporter help page; it exports on demand or to a schedule, with email or server delivery; confirm the options in your installed release.

Separate warehouse stock from delivery routing

Modern PrestaShop does not expose the old 1.6 multi-warehouse ASM administration workflow. Legacy Advanced Stock Management (ASM) was a core feature in PrestaShop 1.6. Retained legacy tables do not make it a current warehouse system.

For modern simple stock, stock_available is authoritative. Do not treat it as a cache that must equal all physical units in legacy stock. For an actual legacy ASM-dependent product, reconciliation must respect usable/real quantities, shop and warehouse associations and combinations. An unscoped sum of physical warehouse stock is not a valid discrepancy check.

A warehouse extension may maintain its own materials, locations, reservations and stock model. Decide which system is authoritative and how it projects sellable stock into PrestaShop.

Origin-specific carriers alone do not implement allocation. A delivery rate must use the resolved origin through explicit carrier-selection logic or a live-rate integration. Modern core retains legacy warehouse fields for compatibility; those fields do not enforce old warehouse/carrier rules.

Work through a basket supplied from different locations

A Paris customer orders products held in Hamburg and Barcelona. Before quoting delivery, establish whether the selected route can supply the whole basket from a location or needs separate parcels. Do not advertise a Hamburg-origin rate and date if the accepted allocation later dispatches from Barcelona.

1. Resolve the intended location for each line and check its sellable stock.
2. Calculate the carrier offer from that allocation, including separate charges where agreed, and show the corresponding delivery promise.
3. If stock or the delivery address changes, revalidate the allocation and the checkout offer before accepting the order.
4. Check that the fulfilment records retain the accepted allocation, or use an agreed exception process when staff must change it.

This is an acceptance scenario for your chosen integration, not a claim that a country-mapping rule automatically chooses the cheapest or nearest warehouse.

Record transfers as linked dispatch and receipt movements. Track goods in transit, damage and receiving differences. Set location-level reorder policies where you maintain independent physical pools.

The warehouse module provides its own warehouse and fulfilment model, with delivery-country mapping to a main warehouse and a default fallback; consult its help page for supported inventory, purchasing and fulfilment workflows.

That routing is not a nearest-location or automatic alternative-stock search. Its warehouse default carrier and fulfilment carrier records do not, by themselves, provide origin-dependent checkout carrier sets. Test checkout rates and allocation together before adding a location.

Sell before stock arrives with a clear promise

A pre-order normally concerns a product not yet released. A backorder normally concerns a previously available item awaiting replenishment. Both can use permission to order when stock is unavailable, but their customer promises differ.

1. Set a deliberate global default under Shop Parameters > Product Settings. Deny out-of-stock orders where you cannot promise replenishment.
2. For eligible products, select Allow orders in the stock section. The underlying out_of_stock values are 0 for deny, 1 for allow and 2 for the global default.
3. Set an honest availability message and, where applicable, availability date. Check the rendered theme.
4. State separately when the item becomes available, when you expect dispatch and when delivery is expected.
5. Repeat the promise in confirmation and delay messages. Check the rendered order_conf email in each selling language, not only the product label. Notify customers when a delay becomes known, with a revised promise and cancellation route. Use a suitable order status to make waiting orders easy to find.

The availability date is not a calculated delivery estimate. It does not add handling or carrier transit time. Button wording and mixed-cart messages depend on the theme or additional development.

Allocate confirmed incoming capacity

Allowing out-of-stock orders can continue into negative quantities. For a limited run, use a hard allocation limit if overselling must be prevented. Manual monitoring and changing to deny orders can leave a race between simultaneous checkouts. Base the remaining allocation on confirmed supplier capacity after existing commitments across all channels. Test simultaneous attempts for the last allocation, a failed payment and a cancellation. Agree which event releases the allocation, and ensure a repeated notification cannot release it again.

Payment timing

Compare full payment, authorisation followed by capture, and deposit plus balance. Check gateway authorisation expiry, capture/refund support, customer information and accounting. Deposits and deferred capture require an implemented payment workflow; they are not supplied by the out-of-stock toggle.

For EU consumer sales, the Consumer Rights Directive generally provides a 14-day withdrawal period linked to possession of goods, with exceptions and special rules. Delivery is due within 30 days unless another time is agreed. Late-delivery remedies depend on the circumstances. A deposit is not automatically a non-refundable administration fee. Check the applicable national rules and product exceptions.

Track cancellations, promised-versus-actual dispatch, support enquiries and repeat purchases against your own baseline. Do not use a universal cancellation threshold or product-price cutoff.

Handle mixed carts and split fulfilment

Decide whether available and incoming-stock lines will ship together, ship separately or be prevented from sharing a cart. Tell the customer before payment, including additional shipping charges and separate tracking.

Core can generate packages and multiple orders during checkout. Its stock-based grouping depends in part on allow_seperated_package. This capability is different from splitting fulfilment after an order exists, and it does not guarantee a partial-delivery interface in your installation.

If you must prohibit mixed carts, enforce an actual cart-validation rule or a dedicated purchase flow. Separate categories and navigation paths do not prevent a customer from adding both products to one cart.

Test the selected flow for discounts, taxes, shipping charges, payment totals, emails, invoices, refunds and every parcel's tracking. Use the shipping guide and order workflow guide when documenting operations.

Choose listing, URL and availability behaviour

Purchase permission, listing visibility and the response of a product URL are separate decisions. Denying out-of-stock orders does not automatically hide the product.

Product visibility can be everywhere, catalogue only, search only or nowhere, and it does not switch by itself when stock reaches zero. For a temporary shortage, compare placing unavailable products last with filtering them from listings while keeping useful direct URLs, and confirm that the listing restores the intended position after restocking. Keeping an active direct URL reachable is different from disabling the product. A disabled product's configured response can be a redirect or an error; PrestaShop 9 also supports additional response choices. Inspect the actual status and destination with your browser tools or an HTTP request.

In PrestaShop 1.7.8, available_later supplies the allowed-backorder message, while denied stockouts use the global denied-order label. PrestaShop 9 has broader per-product fallback support. Check the product page, listing and selected combination in your theme. Follow the same item from a category, internal search and its direct URL, including a link selecting an unavailable combination. Confirm that the listing, buy button and availability text reflect your separate policies. If a module filters unavailable products, test its interaction with faceted search, pagination and caches after a restock.

Match structured data to the actual offer: OutOfStock, PreOrder, BackOrder, InStock or Discontinued as appropriate. Validate rendered output with Google's product testing tools. Accurate markup does not guarantee rankings or rich results.

Customer restock notifications require the relevant mail-alert functionality, such as the installed and configured ps_emailalerts module. Test sign-up, combination matching and the notification after restocking.

Evaluate category clutter using a test that accounts for seasonality, traffic and availability. Two successive 30-day periods alone do not establish an improvement. Avoid irrelevant redirects made solely to eliminate 404 responses.

Model variants and import them safely

A T-shirt size/colour grid is a natural combination model. Distinct laptop specifications or phone-case models may merit separate products if the buying information differs. Features describe the item; attributes create selectable combinations.

1. Define groups and values under Catalog > Attributes & Features, with the suitable selector type.
2. Generate only combinations you sell. Three sizes and two colours create six rows; five sizes, eight colours and three materials create 120.
3. Assign stable unique references, identifiers, quantities, fixed price/weight impacts, images, minimum purchase quantities and availability dates.
4. Choose the default combination and test the first displayed price and stock.

Recognise a configurator requirement

A made-to-measure blind needs entered dimensions, compatible materials and a calculated price. Building a combination for every possible dimension makes the catalogue stand in for rules it does not express. Write down the valid ranges, dependencies and pricing rules first; use a configurator when those rules determine what can be sold. Check that the accepted dimensions, options and price survive into the order and production instructions, rather than appearing only in a browser preview.

The PrestaShop Custom Product Configurator Build service covers one product family with confirmed dimension, compatibility and pricing rules.

Core filters later attribute groups against preceding selections. Its out-of-stock option settings and your theme affect what remains visible. This is distinct from a full rules-based configurator.

For CSV work, select Advanced Parameters > Import > Combinations. Map parent IDs or enable the appropriate parent-reference matching option. Include a unique combination Reference; a parent reference alone cannot identify which existing combination to update.

Product reference;Attribute (Name:Type:Position);Value (Value:Position);Reference;Quantity;Impact on price
TSHIRT-001;Size:select:0,Colour:color:1;M:1,Blue:2;TSHIRT-M-BLUE;45;0
TSHIRT-001;Size:select:0,Colour:color:1;L:2,Red:1;TSHIRT-L-RED;3;2.00

Map these columns in the importer; header text alone does not configure the mapping. Test a second import using the same combination references and changed quantities. Confirm that it updates the intended rows without creating duplicates.

Combination price impacts are fixed amounts. Specific prices can apply context-specific prices or discounts, subject to selection priorities. Tax and currency presentation are separate. Test the final price rather than assuming every rule stacks.

Combinations can have selectable URLs containing a combination ID or attribute fragment. Core normally provides a parent canonical URL; separate indexing is another question. Theme markup varies, including Classic and Hummingbird. Inspect the rendered canonical and offer rather than assuming one shared literal URL or one universal script filename.

If variant images, prices or labels fail to update, check combination data, image associations, requests, JavaScript errors, theme behaviour and interfering modules. For catalogue-wide attribute operations, consult the attribute-template help page.

Plan supplier feeds and dropshipping responsibilities

PrestaShop stores suppliers, supplier references and product costs, and provides carrier configuration. A supplier record is not an automated stock feed, supplier order or fulfilment connector.

1. Agree supplier stock, pricing, dispatch, returns, tracking and exception handling.
2. Map stable supplier references to the correct product or combination.
3. Implement and test the actual CSV, XML or API connector. Define update frequency, stale-feed handling, retries, currency/tax conversion and quantity safeguards.
4. Route orders through a fulfilment integration and confirm supplier acceptance.
5. Track each shipment and communicate split dispatches.
6. Test a stock change, price change, unavailable SKU, failed import, refund and supplier cancellation.

Do not let a feed overwrite local reservations with an unrelated supplier total. Decide whether the supplier quantity is dedicated to you or shared with other sellers. Denying out-of-stock orders helps only when your published quantity is current.

Rehearse a missing supplier record

A feed file downloads successfully but no longer contains a previously listed combination. Establish whether the source is a complete snapshot, a file of changes or an incomplete export before deciding what absence means. A missing row must not silently become either unlimited availability or a confirmed zero without an agreed rule. Test a truncated file, an unknown supplier reference and a repeated run, then check the affected quantities and protected local fields.

Record the last successful application as well as the last download. Give staff a stale-feed warning and an agreed response, such as withdrawing an unreliable promise or holding affected products for review. A successful scheduler run is not evidence that fresh stock reached the correct combinations.

Dropshipping reduces the inventory you hold, but leaves acquisition costs, payment fees, support, refunds, quality risks and compliance work. Compare suppliers using samples and actual dispatch/returns data. Negotiated volume pricing depends on the contract. Supplier location alone does not guarantee profitability.

Write useful product content and add your own specifications and guidance. Duplicate supplier descriptions are not automatically barred from ranking; search engines can deduplicate similar pages and select a canonical.

The warehouse module's uploaded CSV imports and internal stock projection are separate from scheduled external supplier-feed polling. For bulk formula-based catalogue price changes, use the Mass Price Updater help page. For revenue, recorded costs and profit/loss reporting, use the Financial Revolution help page.

Budget a supplier-feed connector and product/supplier cost allocation separately when you need them. Calculate profitability after supplier charges, shipping, acquisition, processing, support and expected returns, then validate with actual orders.

Rehearse the change and plan the switch

Keep evidence for representative simple products, combinations, packs where used, backorders and each stock pool. Include a checkout from each selling market where carriers or promises differ. Record the quantities before the action, the resulting order and movements, and what each connected system receives.

1. On staging, test order creation through your payment and status workflow, dispatch, cancellation before dispatch and a returned item with and without restocking. Confirm that every quantity changes only as intended.
2. Interrupt the connector, create a permitted test event and restore it. Check that missed changes are recovered and a retry does not apply an order, receipt or return again.
3. Rehearse the opening balance and any unshipped orders, incoming receipts and goods in transit. Mark which commitments that balance already includes so the new system does not reserve them again.
4. Agree the switch window and stop competing stock writers. Take the final reconciliation, account for changes since the rehearsal and enable the chosen route in the tested order.
5. Watch the first live sales, receipts and connector acknowledgements against the agreed stock master. If you revert, reconcile events processed since the switch before restoring the previous route.

What to ask your developer or agency

• Which system owns quantities, reservations, supplier costs, retail prices and product content, and which fields may each connector write?
• Which product, combination and shop identifiers are used, and where is an unmatched or ambiguous record reported?
• How are updates ordered, retried and reconciled after an outage, and how can staff distinguish a delayed event from a failed one?
• Where are the test results for our theme, modules, checkout carriers and order states, including concurrent attempts where allocation is limited?
• Who reviews a failed feed, disputed count or changed dispatch promise, and what can they safely correct without another integration overwriting it?

Questions owners ask

What if my supplier only reports “in stock”?

Treat it as an availability signal, not a measured quantity reserved for your shop. Agree a conservative selling policy, how supplier acceptance is confirmed and what happens when it refuses an order. Do not convert the label into a large invented stock balance.

Can products with matching attributes share the same stock?

Matching size or material names do not link their quantities. If several finished products consume the same component, you need a model that reserves that component across them and projects what remains sellable. Confirm the consumption and release rules before enabling sales.

Can I keep the spreadsheet?

Keep it for planning or reporting if it uses a dated export and has a clear purpose. Avoid an editable parallel stock balance that staff copy back over newer orders. Supplier lead-time notes can remain separate from the system that owns live quantities.

Should every customer return go straight back on sale?

Inspect the item and record whether it is resaleable, damaged or awaiting a decision before releasing it. A refund and a parcel's arrival are separate from permission to sell its contents again. Agree who can approve that release.

How do I know the new process is ready?

Your team can trace a test sale, receipt, cancellation and return through the stock master and connected systems, recover an interrupted update and explain the resulting balance. Keep the written test results and exception instructions at handover; a dashboard with plausible totals is insufficient evidence.