Почему остатки на сайте и остатки на складе — это две разные цифры
Практически каждый интернет-магазин, который дорос до нескольких сотен заказов в месяц, проходит через одну и ту же историю. Покупатель оформляет заказ, оплачивает его, а через день менеджер звонит и извиняется: товара нет. Формально сайт не соврал: в карточке действительно стояла единица. Просто эту единицу утром продали в офлайн-точке, вечером её же зарезервировали под другой заказ, а вернуть товар от предыдущего покупателя забыли провести. Цифра на сайте перестала иметь отношение к тому, что реально лежит на полке.
Складской учёт 1С-Битрикс существует ровно для того, чтобы эту связь восстановить: количество товара перестаёт быть полем, которое кто-то правит руками, и становится результатом проведённых документов. Ниже — разбор того, как этот механизм устроен, что нужно подготовить до включения и где чаще всего ломается связка «заказ — резерв — отгрузка».
Количественный учёт и складской учёт — не синонимы
Это первое место, где путаются даже опытные контент-менеджеры. В «1С-Битрикс: Управление сайтом» есть два разных режима, и включаются они отдельно.
Количественный учёт — это режим работы с товарами, при котором у позиции есть поле «Доступное количество», и оно меняется либо вручную, либо автоматически после оформления заказов покупателями. Включается он глобально в настройках модуля «Торговый каталог» и дополнительно может настраиваться индивидуально в карточке конкретного товара. Здесь же живут настройки вроде разрешения или запрета покупки товара, которого нет в наличии. Никакой информации о том, где лежит товар, этот режим не хранит: есть одно число на всю систему.
Складской учёт — надстройка следующего уровня. Он позволяет управлять складами, вести учёт поступлений и списаний товара, и остатки при нём рассчитываются автоматически, на основании документов. Учёт товаров интернет-магазина в этом режиме перестаёт быть ручной работой: вы не правите число, вы проводите приход, перемещение или списание, а система пересчитывает остатки сама.
Важный нюанс, который экономит недели споров с подрядчиком: при отключённом складском учёте информация о количестве товара на складах остаётся справочной и требует ручного изменения. То есть завести склады в системе и заполнить по ним цифры можно и без включённого режима, но эти цифры ни на что не влияют и ни с чем не связаны. Именно так выглядит половина «внедрений складского учёта», которые нам приносят на доработку.
Что реально умеет складской учёт в 1С-Битрикс
Смысл простой: товарооборот идёт через документы. При включённом складском учёте вам доступны:
- Приход товара на склад: оформление поступления от поставщика с указанием количества и склада.
- Перемещение между складами: например, переброска партии с основного склада в точку выдачи или из одной точки в другую.
- Возврат товара: возврат позиции обратно в оборот.
- Списание товара: брак, недостача, порча, внутренние нужды.
- Отмена резервирования: снятие товара из резерва.
Все проведённые операции отражаются в карточке товара автоматически. Плюс появляется нормальная отчётность: остаток по товарам на складах, запасы товаров, история движений: когда, какой товар, в каком количестве и кто отгружал. Отчёты выгружаются в Excel, что закрывает вопрос сверки с бухгалтерией и с поставщиками без выгрузок «из базы через разработчика».
Отчётность здесь имеет смысл не только для сверки с бухгалтерией. Как только накапливается два-три месяца корректной истории движений, появляется возможность считать оборачиваемость: какие позиции уходят за неделю, а какие лежат полгода и замораживают деньги. Это тот уровень данных, ради которого учёт обычно и затевают. Закупки перестают строиться на ощущениях менеджера и начинают опираться на реальную скорость продаж по каждой группе. Магазины, которые доходят до этого этапа, почти всегда обнаруживают две вещи одновременно: часть ассортимента можно спокойно выводить, а по нескольким ходовым позициям компания хронически живёт в дефиците и теряет заказы, просто раньше это не было видно в цифрах.
Отдельно стоит упомянуть работу со штрихкодами: система позволяет учитывать товары по штрих-коду, и на приёмке или отгрузке это заметно ускоряет процесс по сравнению с поиском позиции по названию. Для магазина с ассортиментом в несколько тысяч SKU это не бонус, а необходимость.
Ограничение по редакциям: сколько складов вам доступно
Здесь бизнесу нужно принять решение ещё до старта работ. В редакции «Малый бизнес» действует ограничение: можно использовать только один склад. Многоскладовость — несколько складов, перемещения между ними, раздельные остатки по точкам — доступна начиная с редакции «Бизнес».
Практический смысл простой. Если у вас один физический склад и никаких пунктов выдачи, «Малого бизнеса» хватает: вы получаете документооборот, автоматический пересчёт остатков и отчёты. Если же есть шоурум, точка выдачи, склад партнёра или региональные подразделения — и вы хотите показывать покупателю наличие по конкретной точке — вопрос апгрейда редакции надо закладывать в бюджет сразу, а не обнаруживать его в середине внедрения.
Мы обычно советуем задать себе один вопрос: планируете ли вы в течение ближайшего года открывать вторую точку выдачи? Если да, дешевле сразу проектировать структуру складов «на вырост», чем потом переносить историю движений между конфигурациями.
Подготовка каталога: этап, который пропускают и потом жалеют
Само включение режима занимает минуты. Основная работа — до него. Складской учёт беспощаден к беспорядку в каталоге: он превращает мусор в данных в мусор в остатках, только теперь ещё и с документами.
Что нужно привести в порядок:
- Уникальность позиций. Дубли товаров — главный враг учёта. Если одна и та же деталь заведена трижды разными менеджерами, вы получите три независимых остатка, и ни один из них не будет правдой.
- Артикулы и внешние коды. Если планируется обмен с 1С, каждая позиция должна иметь стабильный идентификатор. Иначе при первой же синхронизации система создаст дубли вместо обновления существующих карточек.
- Торговые предложения. Если товар продаётся в вариантах — размеры, цвета, объёмы — учёт ведётся именно по предложениям, а не по родительскому товару. Структуру нужно проверить до того, как по ней начнут проводиться документы.
- Единицы измерения. Штуки, метры, комплекты, упаковки. Расхождение между тем, как товар приходит от поставщика, и тем, как он продаётся, — источник систематической ошибки в остатках.
- Стартовые остатки. Их нужно ввести документами, а не проставить руками в карточках, иначе первый же отчёт по движению будет бессмысленным.
По нашему опыту, на проектах с каталогом от трёх тысяч позиций подготовка данных занимает больше времени, чем вся техническая часть настройки. Это нормально и это надо честно закладывать в план.
Как включается складской учёт: последовательность
Технически включение живёт в административной части: «Настройки» → «Настройки продукта» → «Настройки модулей» → «Торговый каталог». Там же настраиваются связанные параметры — количественный учёт и резервирование.
Рабочая последовательность, которой мы придерживаемся на проектах:
- Снять полный бэкап сайта и базы. Изменение режима учёта затрагивает данные каталога, поэтому откат должен быть возможен.
- Проверить и, если нужно, вычистить каталог по пунктам выше.
- Завести структуру складов: сколько их, как они называются, какой основной.
- Включить количественный учёт, убедиться, что заказы корректно уменьшают количество.
- Включить складской учёт и ввести начальные остатки документами прихода.
- Настроить резервирование и сверить его со статусами заказов в модуле «Интернет-магазин».
- Раздать права: кто может проводить приход, кто — списание, кто вообще не должен видеть этот раздел.
- Прогнать тестовые сценарии на копии: заказ, отмена заказа, частичная отгрузка, возврат.
Пункт про права доступа часто откладывают «на потом». Не стоит: списание товара — это операция, которая уменьшает остаток без продажи, и доступ к ней должен быть у ограниченного круга людей.
Резервирование: где чаще всего ломается связка
Резервирование — самая деликатная часть настройки, потому что она соединяет два модуля: «Торговый каталог» и «Интернет-магазин».
Сам механизм включается отдельной опцией в настройках модуля «Торговый каталог». Там же задаётся правило, по которому товар попадает в резерв, — параметром «Когда резервировать товар». Работать резервирование будет только для тех позиций, по которым ведётся количественный учёт: без учёта количества резервировать попросту нечего.
Дальше начинается зона, где живут ошибки. Списание товаров из резерва выполняется при отгрузке заказа, а сам момент отгрузки определяется поведением статусов заказа в настройках модуля «Интернет-магазин». Если статусная модель в магазине настроена «как получилось» — а так бывает почти всегда, когда её никто не проектировал, — резерв либо не снимается вовремя, либо снимается раньше времени. Симптомы: товар числится в резерве по давно закрытым заказам, доступное количество медленно уползает в ноль, а на складе при этом всё лежит.
Второй параметр, который стоит осознанно настроить, — период автоматического снятия резерва, если покупатель не проявляет активности. Без него брошенные корзины и неоплаченные заказы будут месяцами держать реальный товар. Есть и настройка автоматического списания при разрешении доставки. Её тоже нужно согласовать с тем, как реально работает ваш склад.
Правильный порядок работы здесь обратный привычному: сначала описываете на бумаге бизнес-процесс заказа (какие статусы, что означает каждый, в какой момент товар физически покидает склад), и только потом настраиваете систему под эту схему. Настройка резервирования без описанного процесса — это гадание.
Если остатками управляет 1С: правило одного хозяина
У большинства торговых компаний учётная система — это «1С», а сайт — витрина. Обмен между ними построен на протоколе CommerceML (поддерживаются версии 2.0 и 2.09), и при настройке выгрузки есть отдельный флажок «Выгружать остатки»: если он включён, для выгружаемых товаров передаются остатки, причём только по тем складам, которые удовлетворяют заданному условию.
Здесь возникает главный архитектурный вопрос всего проекта: кто является источником истины по остаткам. Ответ должен быть один, и он должен быть зафиксирован письменно.
Если хозяин остатков — «1С», то складской учёт на стороне сайта в полном объёме, скорее всего, не нужен: сайт получает цифры и показывает их, а документы прихода и списания оформляются в учётной системе. Попытка вести документы одновременно в двух местах гарантированно приведёт к расхождению: вопрос только в том, через неделю или через месяц.
Если же хозяин — сайт (типично для магазинов, которые выросли из интернет-торговли и не имеют полноценного бухгалтерского контура товародвижения), то складской учёт в 1С-Битрикс работает как основной инструмент, а в «1С» уходят уже заказы и документы реализации.
Промежуточный вариант — разделение по складам: часть складов ведётся в учётной системе, часть на сайте. Он рабочий, но требует дисциплины и чёткого регламента, кто и что проводит. Именно этот сценарий чаще всего разваливается на практике из-за человеческого фактора, а не из-за техники.
Иллюстративный пример: магазин запчастей с двумя точками
Чтобы всё вышесказанное было предметным, разберём типовую ситуацию (пример собирательный, для иллюстрации логики принятия решений).
Магазин автозапчастей: центральный склад и пункт выдачи в другом районе города. Каталог около шести тысяч позиций, из них ходовых — примерно восемьсот. Продажи идут через сайт, по телефону и через прилавок в пункте выдачи. Учётная система — «1С», но заведена в ней только бухгалтерия, товародвижение ведётся в таблицах.
Что даёт разбор ситуации:
- Складов два, значит редакция «Малый бизнес» не подходит: нужна многоскладовость.
- Источник истины по остаткам — сайт, потому что в «1С» товародвижения фактически нет. Значит складской учёт на 1С-Битрикс ставится как основной контур, а не как витрина.
- Прилавок в пункте выдачи означает, что продажи идут не только через заказы сайта. Эти продажи должны попадать в систему документами списания или через кассовое решение, иначе остаток пункта выдачи начнёт врать в первую же неделю.
- Восемьсот ходовых позиций — это тот объём, где имеет смысл начинать со штрихкодов и приёмки по сканеру, а не пытаться охватить сразу весь каталог.
- Статусная модель заказа должна различать «собран на центральном складе» и «передан в пункт выдачи», иначе резерв и перемещение будут конфликтовать.
Обратите внимание: ни один из этих выводов не про кнопки в админке. Все они про бизнес-процесс. Техническая настройка — последний шаг, и она занимает меньшую часть проекта.
Пять ошибок, которые повторяются на каждом втором проекте
Включить складской учёт «чтобы было». Если никто в компании не готов ежедневно проводить документы, режим только добавит работы и очень быстро начнёт показывать неправду. Складской учёт — это не настройка, а операционная дисциплина.
Ввести стартовые остатки руками. Соблазн понятен, но после этого история движений теряет смысл, и первый же вопрос «откуда взялась эта цифра» останется без ответа.
Не разобраться со статусами заказов. Резерв, который не снимается, — самая частая жалоба после внедрения. Причина почти всегда в статусной модели, а не в модуле складского учёта.
Оставить возможность продавать в минус без осознанного решения. Настройка разрешения покупки при отсутствии товара — это бизнес-решение. Для товаров под заказ она уместна, для складских позиций обычно нет. Проблема в том, что её редко принимают осознанно.
Включать сразу «в бою», на живом сайте. Смена режима учёта затрагивает данные каталога и логику оформления заказа. Всё, что касается складского учёта, отрабатывается на тестовой копии: там вы спокойно проходите сценарии отмены заказа, частичной отгрузки и возврата, ловите неприятные сюрпризы и только после этого переносите настройки на продакшн, с бэкапом и планом отката.
Не назначить владельца процесса. Если за корректность остатков не отвечает конкретный человек, через три месяца система вернётся в состояние «посмотрите в таблице, там точнее».
Что закладывать в проект по срокам и этапам
Внедрение складского учёта — это не задача «на вечер», даже если сама галочка ставится за минуту. Реалистичная структура работ выглядит так: обследование и описание бизнес-процесса товародвижения, аудит и чистка каталога, проектирование структуры складов и статусной модели, настройка на тестовой копии, ввод начальных остатков, обучение сотрудников, сопровождение первых недель работы.
Последний пункт критичен и его почти всегда недооценивают. Первые две-три недели после запуска — это период, когда всплывают все нештатные ситуации: пересорт, возврат части заказа, товар, который физически уехал, но документально остался. Если в этот момент рядом нет специалиста, сотрудники начнут «исправлять» остатки вручную, и вся конструкция обесценится.
Мы проходим этот путь с клиентами регулярно: от аудита каталога до настройки обмена и обучения менеджеров. Если вам нужна не консультация, а результат, посмотрите наши услуги по разработке и доработке сайтов: складской учёт мы обычно ведём как отдельный этап внутри проекта развития интернет-магазина, с обязательной работой на тестовой копии и планом отката.
И последнее, что стоит держать в голове. Складской учёт на 1С-Битрикс — это инструмент, который делает видимой реальную дисциплину вашей компании. Если товародвижение в порядке, он превращает его в цифры, которым можно доверять и на которых можно строить закупки. Если беспорядок, он его не исправит, а просто покажет в отчётах. Хорошая новость в том, что увидеть проблему — это уже половина решения, и большинство наших клиентов после первого месяца работы с документами обнаруживают в остатках вещи, о которых до этого просто не знали.
Частые вопросы
Можно ли вести складской учёт в редакции «Малый бизнес»?
Да, но с ограничением: доступен только один склад. Если вам нужны несколько складов и перемещения между ними, потребуется редакция «Бизнес» или старше.
Чем количественный учёт отличается от складского?
Количественный учёт — это одно поле «доступное количество» на товар, которое меняется вручную или после заказов. Складской учёт добавляет склады и документы: приход, перемещение, списание, возврат. Остатки считаются автоматически на основании этих документов.
Что делать, если товар «висит в резерве» по старым заказам?
Проверять две вещи: настройку периода автоматического снятия резерва в модуле «Торговый каталог» и поведение статусов заказа в модуле «Интернет-магазин». Списание из резерва привязано к отгрузке, а момент отгрузки определяется именно статусной моделью.
Нужен ли складской учёт на сайте, если у нас уже есть «1С»?
Как правило, нет, если товародвижение реально ведётся в «1С». Тогда сайт получает остатки через обмен по CommerceML и работает как витрина. Дублировать документы в двух системах не стоит.
Сломается ли что-то в работающем магазине при включении складского учёта?
Риск есть, поэтому включение всегда делается на тестовой копии с полным бэкапом. Проверять нужно сценарии оформления заказа, отмены, частичной отгрузки и возврата. Именно там проявляются последствия смены режима.