Остатки и склад: как не продать то, чего нет

Остаток на сайте — это не одно число. Это как минимум три: сколько физически лежит на складе, сколько зарезервировано под неоплаченные заказы и сколько можно продать прямо сейчас. Когда магазин хранит только первое, он рано или поздно продаёт то, чего нет. Разберём, как устроен нормальный учёт остатков и где он ломается.

Три числа вместо одного

Физический остаток. Сколько единиц реально лежит на полке. Меняется при поступлении товара и при отгрузке.

Резерв. Сколько единиц обещано покупателям, чьи заказы созданы, но ещё не отгружены. Это не проданный товар и не свободный товар — он в промежуточном состоянии.

Доступно к продаже. Разность первых двух. Именно это число видит покупатель на витрине и именно оно проверяется при оформлении заказа.

Магазин, который показывает физический остаток, ведёт себя предсказуемо плохо: пока заказ собирается, товар остаётся в продаже, и его успевают купить ещё раз.

Жизнь одной единицы товара

Проследим путь одной штуки от поступления до отгрузки.

1. Поступление. Приехала партия, физический остаток увеличился. Товар доступен к продаже.
2. Заказ создан. Покупатель оформил заказ. Единица уходит в резерв. Физический остаток тот же, доступно к продаже стало на единицу меньше.
3. Оплата пришла. Резерв подтверждён. Теперь это обязательство, которое нельзя снять автоматически.
4. Заказ собран и отгружен. Физический остаток уменьшается, резерв закрывается.
5. Возврат, если он случился. Товар возвращается на склад, физический остаток растёт.

Между вторым и третьим шагом есть развилка, о которой чаще всего забывают. Если оплата не пришла, резерв должен сняться сам — по истечении срока. Иначе неоплаченные заказы постепенно съедают весь склад, а на витрине висит «нет в наличии» при полных полках.

Срок жизни резерва — это бизнес-решение, а не техническое. Для товара, который разбирают, он короткий. Для редкого — можно подержать дольше.

Момент, когда двое покупают последнюю штуку

Самое неприятное место в учёте остатков. Двое одновременно кладут в корзину последнюю единицу и одновременно оформляют заказ.

Если проверка остатка и создание заказа — два раздельных шага, оба покупателя проходят проверку успешно. Оба получают подтверждение. Один из них потом получает извинения.

Правильное поведение: проверка доступности и постановка в резерв должны быть одним неделимым действием на стороне сервера. Проиграл — увидел честное «осталась одна штука, её только что забрали» до оплаты, а не после.

Проверка остатка только в браузере не считается вообще. Она нужна для удобства, а решение принимается на сервере.

Несколько каналов продаж

Пока канал один, всё просто. Как только появляется маркетплейс, розничная точка или второй сайт, возникает вопрос: кто ведёт счёт.

Единственный работающий ответ — один источник правды. Одна система хранит остаток, все остальные каналы получают его выгрузкой и не имеют права менять самостоятельно.

В магазине «Жук и Плут» товары приходили импортом с Wildberries, и первое, что пришлось решить, — где теперь живёт настоящее количество. Пока такой договорённости нет, каждый канал считает по-своему, и расхождение накапливается тихо.

Мгновенной синхронизации не бывает: выгрузка идёт с задержкой, и в этот промежуток одна и та же единица может уйти дважды. Отсюда практика буфера — на каналах, которые вы не контролируете, показывать чуть меньше, чем есть.

Поступления и пересорт

Остаток растёт не сам по себе, а от поступления. Проведение поступления — это отдельное действие с документом: что приехало, сколько, по какой цене, когда.

Здесь же обычно всплывает пересорт: приехало не то, что заказывали, или не в том количестве. Если система умеет проводить поступление только целиком и без расхождений, кладовщик начнёт править остатки руками, и вся история движений потеряет смысл.

Поэтому расхождение при приёмке должно фиксироваться как расхождение, а не как ручная корректировка. Разница между этими двумя записями в том, что первую можно потом разобрать с поставщиком, а вторую — нет.

Что должно быть видно в админке

Складской модуль — это не таблица с числами. Это ответ на вопрос «почему количество такое».

• Текущие три числа по каждой позиции: физически, в резерве, доступно.
• История движений: когда, сколько, по какой причине, кто сделал.
• Список активных резервов с заказами, к которым они относятся.
• Позиции ниже порога, при котором пора заказывать.
• Отдельно — позиции, где остаток ушёл в минус. Такое случается, и это сигнал об ошибке в учёте, а не повод округлить до нуля.

История движений важнее всего остального. Без неё расхождение между сайтом и полкой невозможно разобрать — остаётся только пересчитать всё руками.

Кто и что может менять

Остаток — это деньги, поэтому права здесь такие же важные, как в разделе оплат.

Мы почти в каждом проекте ставим один и тот же узел: сборщик видит заказы, но не видит деньги; менеджер видит клиентов, но не видит настройки. Со складом та же логика. Кладовщик проводит поступление и отгрузку. Корректировать остаток вручную, задним числом и без причины не должен никто, кроме владельца, и каждая такая правка обязана оставлять след с указанием причины.

Ручная корректировка без комментария — самый быстрый способ потерять доверие к цифрам в системе.

Кому складской модуль не нужен

Магазину, который делает товар под заказ. У ToYou Wood мебель считается по размерам и производится после оплаты — остатков в привычном смысле там нет, есть загрузка производства, и это другая задача.

Магазину с несколькими десятками позиций, которые не заканчиваются внезапно. Поле количества в карточке товара закроет вопрос полностью.

Магазину, у которого уже есть учётная система и она работает. Тогда задача не в модуле, а в выгрузке остатков из неё на сайт, и это заметно дешевле. Ориентиры по стоимости работ — на странице цен.

Коротко

Учёт остатков начинается с разделения на физическое количество, резерв и доступное к продаже. Резерв ставится при создании заказа и обязан сам сниматься, если оплата не пришла. Проверка и резервирование должны быть одним действием на сервере, иначе последнюю штуку продадут дважды. При нескольких каналах нужен один источник правды и буфер на задержку выгрузки. А если позиций немного и они не кончаются внезапно, хватит обычного поля количества — модуль будет дороже пользы.