Складской учёт для маркетплейсов: как вести и зачем автоматизировать

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

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

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

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

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

Полезно закрепить простую логику:

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

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

Какие движения нужно фиксировать на складе

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

Минимальный набор складских событий включает:

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

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

Почему резерв защищает продажи сразу на нескольких площадках

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

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

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

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

Как адресное хранение ускоряет сборку

Фраза «товар лежит на складе» слишком неточна для операционной работы. Сотруднику нужен адрес: зона, стеллаж, секция, полка или ячейка. Даже небольшой склад выигрывает от простых читаемых кодов, например A-03-02, если одинаковая логика используется на табличках, в системе и в задании на сборку.

Адресное хранение не требует начинать с идеальной карты помещения. Сначала достаточно разделить склад на функциональные зоны:

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

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

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

Как заказ превращается в проверяемое задание

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

На умном складе для FBS-заказов этот механизм связывает единый доступный остаток с резервом, заданиями, маршрутами, ролями и журналом операций. Адресное хранение подсказывает, откуда взять товар; сборка, маркировка и упаковка проходят как отдельные контролируемые этапы; интеграции с 1С и МоимСкладом помогают не создавать параллельные независимые остатки.

Роли уменьшают число случайных изменений

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

Маршрут должен учитывать не только близость

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

Журнал отвечает на вопрос «что произошло»

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

Как контролировать сборку, маркировку и упаковку

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

Контроль строят через обязательные подтверждения:

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

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

Где проходит граница между складом, 1С и МоимСкладом

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

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

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

Как внедрить складской учёт без остановки отгрузок

Пытаться описать весь склад за один день рискованно. Надёжнее запускать систему на ограниченной зоне или группе SKU и расширять после первой сверки.

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

Семь признаков, что складской учёт требует ремонта

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

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

Главный результат: склад становится воспроизводимым процессом

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

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