Складской учёт и сайт: как избежать продажи отсутствующих товаров

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

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

Почему сайт продаёт отсутствующие товары

Причина обычно не в одной технической ошибке, а в разрыве между фактическим движением товара и информацией, которую видит покупатель. На сайте может быть указано «в наличии», хотя последний экземпляр уже продан в магазине, зарезервирован менеджером или отправлен в другой филиал.

В небольших компаниях остатки нередко обновляют вручную раз в день или несколько раз в неделю. Такой подход ещё может работать для каталога с десятками позиций и редкими заказами. Но при большом ассортименте, сезонном спросе или продажах через несколько каналов ручной контроль становится источником постоянных расхождений.

Типовые причины продажи отсутствующего товара:

• остатки на сайте обновляются по расписанию, а не после каждого изменения;
• у сайта и учётной программы разные артикулы или названия товаров;
• резерв товара создаётся только после звонка менеджера;
• заказы с сайта не передаются в складскую систему;
• один и тот же товар продаётся через сайт, магазин, маркетплейс и отдел продаж;
• в учёте не разделены доступный остаток, резерв и товар в пути;
• обмен между системами прерывается, но никто не получает уведомление об ошибке.

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

Какие данные нужно передавать между сайтом и складом

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

Для большинства интернет-магазинов критичным является именно доступный остаток. Его можно рассчитать как фактическое количество минус уже созданные резервы, если товар не предназначен для продажи с отрицательным остатком. В некоторых сферах дополнительно учитывают минимальный неснижаемый запас, брак, товар на проверке и единицы, отложенные под оптовый заказ.

Например, на складе числится 12 фильтров. Два уже зарезервированы под заказы, один находится на проверке качества, а три оставлены для регулярного клиента. В таком случае на сайте разумно показывать доступными не 12, а 6 единиц, если внутренние правила компании не предусматривают другой расчёт.

Как работает интеграция интернет-магазина со складской системой

Обычно обмен строится в двух направлениях. Из складской или товароучётной системы на сайт передаются карточки товаров, цены, характеристики, изображения, остатки и статусы. С сайта обратно уходят заказы, данные покупателей, выбранный способ доставки и информация об оплате.

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

В зависимости от задач используют несколько вариантов обмена:

• Регулярная синхронизация. Сайт запрашивает изменения через заданный интервал, например каждые 5-15 минут. Подходит для умеренной нагрузки и несложного ассортимента.
• Обмен по событию. Система сразу отправляет уведомление после продажи, возврата или изменения остатка. Такой вариант лучше для товаров с небольшим количеством единиц.
• Периодическая загрузка файла. Остатки передаются в виде подготовленного файла по расписанию. Это проще и дешевле на старте, но между обновлениями остаётся окно риска.
• Связь через программный интерфейс. Системы обмениваются структурированными запросами и ответами. Такой подход удобен при сложной логике, нескольких складах и большом количестве каналов.

Способ обмена выбирают не по популярности технологии, а по цене ошибки. Если отмена одного заказа почти не влияет на бизнес, обновления раз в 15-30 минут могут быть достаточными. Если продаются дорогие позиции, ограниченные партии или товары с высокой оборачиваемостью, лучше уменьшать задержку и вводить строгую проверку резерва.

Резервирование товара, главный механизм защиты

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

В бизнесе нужно заранее определить момент, когда товар считается зарезервированным. Возможные варианты:

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

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

Практичный компромисс для многих компаний, резервировать товар после подтверждения заказа на ограниченный срок. Например, заказ без оплаты хранится в резерве 2-4 часа, после чего резерв снимается автоматически. Срок зависит от продукта, способа оплаты и скорости обработки заявок.

Сайт должен показывать не просто то, что когда-то числилось на складе, а то, что компания действительно готова отгрузить клиенту сейчас.

Не стоит обещать точное количество, если данные обновляются с задержкой. Для нестабильного остатка безопаснее использовать формулировки «уточним наличие», «под заказ» или «осталось мало», но только если эти статусы связаны с понятными правилами, а не назначаются вручную без контроля.

Как показывать наличие на сайте

В карточке товара важно разделить информационный и коммерческий статус. Фраза «есть на складе» должна означать, что позицию можно заказать в заявленном количестве. Если товар есть, но его нужно переместить между складами, клиенту следует сообщить отдельный срок.

Для каталога можно использовать несколько статусов:

• «В наличии», товар доступен для заказа;
• «Мало», остаток ниже установленного порога;
• «Под заказ», поставка ожидается после оформления;
• «Ожидается», известна плановая дата поступления;
• «Нет в наличии», заказать товар сейчас нельзя;
• «Снят с продажи», карточка сохранена для поискового трафика, но покупка недоступна.

Порог для статуса «мало» задают по товарной группе. Для дорогого оборудования остаток 3 единицы может быть достаточным, а для ходового расходного материала это уже сигнал к пополнению. Не следует показывать точное число «осталось 1», если обновление происходит раз в час: за это время позицию могут купить в другом канале.

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

Несколько складов и разные условия доставки

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

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

До настройки обмена зафиксируйте следующие правила:

1. какие склады участвуют в продаже через сайт;
2. какой склад имеет приоритет при сборке заказа;
3. можно ли объединять товары из разных мест хранения;
4. как рассчитывается срок доставки;
5. когда создаётся межскладское перемещение;
6. кто отвечает за расхождение между данными сайта и фактическим наличием.

Если правила не определены, техническая интеграция будет передавать точные, но бесполезные данные. Сайт сообщит, что товар есть, однако не объяснит, откуда его везут и когда клиент его получит.

Что нужно проверить до интеграции

Перед началом работ проводят обследование процессов, а не только устанавливают модуль обмена. Важно понять, где хранится первичная информация и какие действия сотрудников меняют остаток.

Проверка справочника товаров

Сверьте артикулы, единицы измерения, варианты товара и упаковки. Частая ошибка, когда на сайте один артикул используется для коробки из 10 штук, а в учётной системе остаток ведётся по одной единице. В результате покупатель заказывает одну коробку, а система списывает одну штуку.

Проверка заказов

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

Проверка ошибок обмена

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

Проверка прав доступа

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

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

Типичные ошибки при настройке складского учёта

Ошибка 1. Обмен настроили, но процесс не описали

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

Ошибка 2. Синхронизируют только остатки

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

Ошибка 3. Оставляют отрицательные остатки без контроля

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

Ошибка 4. Не тестируют одновременные заказы

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

Ошибка 5. Не учитывают возвраты и отмены

Отменённый заказ может продолжать удерживать резерв, а возвращённый товар может сразу появиться в продаже, хотя ещё не прошёл проверку. Для таких операций нужны отдельные статусы и понятные правила возврата позиции в доступный остаток.

Ошибка 6. Показывают точный остаток при большой задержке

Надпись «осталась 1 штука» создаёт у клиента ожидание гарантированной покупки. Если сайт обновляет данные раз в час, такая точность вводит в заблуждение. Либо сократите интервал, либо используйте более осторожный статус.

Сколько времени и денег занимает настройка

Срок зависит от количества систем, качества справочника товаров, числа складов и сложности правил заказа. В типичном проекте простая синхронизация каталога и остатков занимает около 1-3 недель. Если нужно связать сайт с учётной программой, службами доставки, оплатой, несколькими складами и резервированием, работы могут занять 3-8 недель.

По рынку стоимость интеграции может составлять от нескольких десятков тысяч рублей для простого обмена до нескольких сотен тысяч рублей для сложного проекта с индивидуальной логикой. Это ориентир, а не фиксированный прайс: точная смета появляется после брифа и проверки систем.

На бюджет влияют:

• тип сайта и используемая система управления;
• готовность стандартного модуля обмена;
• количество товарных позиций и характеристик;
• число складов и каналов продаж;
• необходимость резервирования в реальном времени;
• правила цен для разных групп клиентов;
• объём очистки и сопоставления справочников;
• нужны ли журнал ошибок, уведомления и отчётность.

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

Как контролировать работу после запуска

Интеграцию нельзя считать завершённой в день включения обмена. Первые 1-2 недели отслеживайте контрольные показатели и сравнивайте данные в системах вручную. Это позволяет заметить ошибки, которые не видны на тестовых товарах.

Минимальный набор проверок:

• время последней успешной синхронизации;
• число товаров с нулевым или отрицательным остатком;
• заказы, не переданные в учётную систему;
• заказы с ошибкой резервирования;
• расхождения между сайтом и складом по выборке ходовых товаров;
• зависшие резервы и заказы без движения;
• возвраты, которые не вернулись в нужный статус.

Полезно составить контрольную выборку из 20-30 товаров: ходовые позиции, товары с вариантами, комплекты, позиции с несколькими складами и товары под заказ. Раз в неделю сравнивайте по ним остаток, цену, статус и историю последних изменений.

Если сайт уже теряет позиции или привлекает посетителей на неактуальные карточки, отдельно проверьте техническую часть и индексацию. Для интернет-магазина также имеет смысл заказать SEO-продвижение интернет-магазина, но только после того, как наличие и структура каталога стали управляемыми. Продвижение товара, который нельзя купить, увеличивает не продажи, а количество разочарованных посетителей.

Частые вопросы

Можно ли обойтись без интеграции, если ассортимент небольшой?

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

Нужно ли показывать точное количество товара?

Нет, это не обязательно. Для большинства категорий достаточно статусов «в наличии», «мало» и «нет в наличии». Точное число полезно, когда оно влияет на решение о покупке, например при оптовом заказе, но только при почти мгновенном обновлении данных.

Что делать, если остатки в учётной системе уже неверные?

Сначала провести инвентаризацию и определить систему, которая будет источником правды. После этого очистить дубли, исправить артикулы, объединить варианты и только затем включать обмен. Интеграция не исправляет исходные ошибки, а переносит их между системами.

Можно ли настроить обмен только для остатков?

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

Как быть с товаром под заказ?

Выделите его в отдельный статус и не смешивайте с обычным наличием. На странице укажите ориентировочный срок поставки, необходимость подтверждения и возможные изменения цены. Такой товар не должен списываться как готовый к отгрузке.

Нужно ли учитывать требования к персональным данным при интеграции?

Да. При передаче заказа между сайтом, учётной системой и сервисами доставки меняется состав и маршрут обработки данных клиента. Проверьте документы, согласия и настройки хранения. Базовые вопросы регулирования разобраны в материале о сайте и 152-ФЗ.

Что делать: короткий план

1. Опишите все каналы продаж и места, где меняется остаток.
2. Назначьте одну учётную систему источником актуальных данных.
3. Приведите к единому виду артикулы, варианты, единицы измерения и статусы.
4. Определите формулу доступного остатка с учётом резервов и минимального запаса.
5. Зафиксируйте момент создания, продления и снятия резерва.
6. Выберите способ обмена и допустимую задержку обновления.
7. Настройте передачу заказов, отмен, возвратов и изменений статуса в обе стороны.
8. Добавьте журнал ошибок и уведомления о сбоях синхронизации.
9. Проверьте одновременную покупку последней единицы, отмену, возврат и заказ из разных складов.
10. После запуска регулярно сравнивайте данные по контрольной выборке товаров.

В практике студии RDMN такие задачи начинаются с разбора товарного учёта и сценариев работы сотрудников, а уже потом переходят к настройке сайта. Это позволяет связать техническое решение с реальным процессом: кто подтверждает заказ, когда товар блокируется и что увидит клиент при изменении наличия.

Главный результат правильно настроенной связки, не просто цифра в карточке товара. Клиент получает честную информацию, менеджер работает с понятным заказом, а руководитель видит управляемый процесс продаж без постоянной сверки таблиц и звонков на склад.