Склад дистрибьютора: ТСД, остатки в реальном времени и связь с продажами

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

Какой остаток показывать продажам

Слово «остаток» на складе дистрибьютора означает минимум пять разных чисел. Продажам нужно одно — свободный остаток.

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

Почему без ТСД остатки всегда опаздывают

На бумажном складе каждая операция живёт дважды: сначала её делают руками, потом вносят в учёт. Между этими моментами — часы, иногда дни. Терминал сбора данных (ТСД) — промышленный смартфон или пистолет со сканером — убирает второй шаг: операция фиксируется в момент сканирования.

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

Как выглядит работа кладовщика со сканером на практике и где чаще всего ошибаются при внедрении — в статье складская программа: сканер, ввод и операция.

Готовое решение для ТСД или своё приложение

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

1. учёт не в 1С или склад работает в собственной складской системе;
2. нужны нестандартные сценарии: сборка под кросс-докинг на РЦ сетей, комплектация наборов, сборка волнами под рейсы доставки;
3. ТСД должен работать в общем контуре с приложением агентов и экспедиторов — один набор справочников, одна синхронизация;
4. нужна логика, которой нет в готовом продукте: приоритеты сборки по окнам доставки, автоматическая блокировка по сроку, правила подбора партий под покупателя.

Мы делаем складские приложения для ТСД на Android и складские программы для рабочих мест кладовщиков и начальника склада. Если склад пока ведётся в «МойСкладе», часть сценариев закрывается его средствами, а недостающее достраивается через интеграцию с МойСклад.

Связь склада с продажами: где ставится резерв

Самый спорный вопрос — в какой момент заказ резервирует товар. Варианты:

Для большинства дистрибьюторов рабочая схема — резерв после автоматической проверки (лимит, просрочка, наличие), с временем жизни для неподтверждённых заказов: если заказ не подтверждён за заданное время, резерв снимается. Главное, чтобы резерв ставился в одной системе для всех каналов — агентов, приложения торговых представителей, портала, сетей и маркетплейсов. Как распределять остаток между каналами при дефиците, мы разбирали в статье заказы сетей, EDI и маркетплейсы.

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

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

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

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

Типичные ошибки при внедрении

• Штрихкоды «потом». Если у части SKU нет штрихкодов или у разных фасовок одинаковый код, сборщики начинают вводить товар вручную, и смысл сканирования пропадает. Справочник чистят до запуска.
• Ячейки без адресов. Без адресного хранения ТСД знает, что товар есть, но не знает где, и сборщик ищет его по памяти.
• Слабый Wi-Fi. В дальних рядах и холодильных камерах связь пропадает. Приложение должно работать офлайн и досылать операции, а покрытие сети стоит проверить до покупки терминалов.
• Старый процесс параллельно навсегда. Бумажные листы сборки «на всякий случай» живут месяцами, и учёт снова расходится. Срок параллельной работы фиксируют заранее.
• Обучение одним днём. Новые сотрудники приходят каждую неделю; нужен короткий регламент по каждой операции прямо в приложении.

План перехода на ТСД без остановки склада

1. Навести порядок в справочниках: штрихкоды у всех SKU, адресация ячеек, единицы хранения и упаковки.
2. Начать с приёмки — на ней ошибки дороже всего, а сценарий проще всего.
3. Затем сборка: сначала одна зона или один тип заказов, параллельно со старым процессом.
4. Перемещения и инвентаризация по ячейкам.
5. Только после этого включать показ свободного остатка в продажах и убирать старые отчёты.

Порядок важен: если начать с показа «реального» остатка до того, как склад научился фиксировать операции сразу, продажи получат новую неправильную цифру вместо старой. А если остатки и закупки ещё и планируются вручную, следующий шаг — автозаказ поставщикам и прогноз спроса.