Shared stock between products, packs and combinations: how not to sell what you don't have

You have a decorative print that you sell on its own and also in a pack of three. Or a dress that has its normal product page and an outlet page with another price. Or the same T-shirt in two collections, with two product pages because each has its own text and photos. In the warehouse there is a single physical stock; in the store, several product pages with their own stock.

The result is predictable: you sell on one page, the others keep showing units that no longer exist, and someone buys what you don't have.

Why PrestaShop does not solve it on its own

In PrestaShop, stock belongs to each product and each combination. Two different products are two different stocks, even if in your head they are the same thing. The store has no way of knowing that the “Blue dress” page and the “Blue dress · Outlet” page come off the same rail.

Native packs help in part: a pack can deduct stock from its components. But they cover one specific case (a pack made of products), not two parallel pages for the same item, nor the cases where you want the pack to have its own page with visible stock.

The most common cases

Three ways to share stock

There is no single correct way. It depends on who is in charge and whether there are ratios.

Shared reserve

There is a pool of physical units and each page draws from it according to its ratio. The single print consumes 1; the pack of three consumes 3. If the pool has 10 units, the single page can sell 10 and the pack, 3. It is the natural option for packs and bundles.

Mirror

All pages show the same quantity. The one that changes (through a sale or restocking) leads, and its quantity is copied to the others. It fits a normal page and its outlet page, or the same garment in two collections, where there are no ratios.

Master

One page is the source of truth —usually the one that corresponds to the warehouse item— and its stock is projected onto the rest. When a derived page sells, it is deducted from the master. It is useful when stock comes from outside (an ERP or an inventory system) into a specific page.

What should move stock (and what should not)

• Sales: always.
• Cancellations and returns: as well, in reverse and in the same ratio.
• Manual edits: it depends. If someone corrects a page's stock after a stock count, you normally want it to propagate; if it is a one-off adjustment to a single listing, perhaps not. Decide, and make it an option rather than a surprise.
• Multistore and warehouses: the group has to know whether it shares across stores or only within one, and which warehouse it comes from.

The mistakes that cause overselling

1. Badly defined ratios. A pack of three configured as 1:1 sells three times more than you have.
2. Simultaneous orders. If two orders read the stock at the same time and each subtracts on its own, one of the subtractions is lost. The deduction has to happen in a single database operation.
3. Two lines of the same order that belong to the same group (the single item and the pack in the same cart) and are deducted separately without taking the other into account.
4. Going below zero. If the reserve can go negative, the pages show absurd quantities. The prudent option is not to go below zero unless you deliberately sell on backorder.
5. A synchronisation failure that breaks the order. Synchronisation must never stop the customer from completing the purchase: if it fails, the order goes through and the failure is logged so it can be fixed.

What the customer sees

Besides the number being correct, you can take advantage of the pages being linked. A notice on the product page along the lines of “this item is also available in…” with the other pages helps the customer looking for the pack find the single item, or the other way round. And it avoids the impression that you have the same product “duplicated” without explanation.

How to start without breaking anything

1. Take stock of the cases: which pages share physical stock and in what ratio.
2. Group them by strategy: packs with a shared reserve, duplicates with a mirror, warehouse listings with a master.
3. Set up a test group first and place orders, cancellations and returns on a copy of the store.
4. Review the movement history: it has to distinguish sales, manual edits and recalculations.
5. Set a low-stock alert threshold per group, so you restock before the common pool runs out.

If your store is on an old version, the test on a copy is also the moment to check that everything works with a current PHP version: stock modules hook into very sensitive points of the order, and the base should be a supported version.

How to solve it in PrestaShop

RKR LinkStock links products, combinations and packs that come from the same physical unit so that a sale deducts the stock of all of them. It has three strategies per group —shared reserve with a ratio per member, mirror minimum and master-driven—, organises groups by warehouse and by master SKU and works in multistore. Sales, cancellations and returns move the group; manual edits do so if you choose. The deduction is done with an atomic operation, the reserve does not go below zero by default and, if synchronisation fails, the order is completed anyway. It shows a shared-stock notice on the product page with the linked pages and includes history, statistics, low-stock alerts and demo data so you can try it without touching your catalogue.