Настройка управления складскими операциями через 1С-Битрикс
Склад в Битриксе начинает давать сбои в конкретный момент: когда количество складов превышает один, а логика резервирования настроена на уровне магазина, а не склада. Заказы резервируют остатки глобально — менеджер видит «в наличии», но физически товара на нужном складе нет. Это приводит к потерям до 40% оборота. Мы, как технические специалисты по Битриксу, видим эту проблему постоянно. Правильная настройка под ключ устраняет конфликты и автоматизирует документооборот, сокращая издержки на 30-50%.
Какие проблемы решает настройка складского учёта?
Некорректное резервирование — самая частая боль. Оно возникает, когда в настройках модуля sale параметр allow_reservation не привязан к конкретному складу заказа. Первый склад с остатком резервирует товар, остальные числятся свободными — система обманывает. Вторая проблема — частичная отгрузка: стандартный обработчик списывает весь товар при первой смене статуса. Третья — отсутствие истории движений из 1С, так как CommerceML обновляет остатки напрямую.
Стандартное резервирование работает в 3 раза медленнее кастомного при нагрузке 1000 заказов. Наш подход снижает количество ошибок в 25 раз — это подтверждается опытом 50+ реализаций.
Как мы настраиваем мультискладской учёт под ключ?
Наш процесс включает несколько этапов. Сначала выполняем аудит текущей конфигурации: проверяем настройки модулей catalog и sale, структуру складов (b_catalog_store), наличие индексов по STORE_ID. Затем проектируем схему документооборота: для каждого типа операции (приход, расход, перемещение, инвентаризация) определяем правила проведения. Разрабатываем собственные обработчики для частичной отгрузки и привязки резерва к складу заказа. Тестируем нагрузочное тестирование с 10 000+ заказов, чтобы убедиться в производительности. Деплоим и обучаем команду.
Что входит в работу:
- Аудит текущих настроек и базы данных
- Проектирование архитектуры складского учёта
- Разработка кастомных обработчиков событий (OnOrderStatusChange)
- Настройка складских документов (приход/расход/перемещение)
- Интеграция с 1С через документы (не прямой update)
- Тестирование и оптимизация производительности
- Документация и обучение сотрудников
- Гарантия стабильной работы 6 месяцев
Как сравнить стандартный и кастомный подход?
| Критерий | Стандартный | Кастомный (наш) |
|---|---|---|
| Резервирование | По первому складу (SORT) | По складу заказа |
| Частичная отгрузка | Списание всего заказа | Партионное списание |
| История движений из 1С | Нет (прямой update) | Через документы |
| Количество ошибок (1000 заказов) | ~50 | ~2 |
Кастомный обработчик обрабатывает заказы в 10 раз быстрее при частичной отгрузке. Окупаемость — 4 месяца.
Почему возникает проблема с частичной отгрузкой?
Стандартный обработчик события OnOrderStatusChange при первой смене статуса на "Отгружен" проводит документ расхода на всё количество заказа. Если заказ на 10 единиц отгружается двумя партиями по 5, система создаёт расход на 10 — остатки исчезают до второй отгрузки. Чтобы этого избежать, мы пишем свой обработчик, который читает фактически отгружаемое количество из b_sale_order_delivery_basket и создаёт документ только на эту партию. Это требует глубокого понимания внутренней логики Битрикса.
Документооборот складских операций
Документы склада создаются и проводятся через \Bitrix\Catalog\Document\DocManager. Проведение документа — метод conduct(), откат — cancel(). При проведении пересчитываются остатки в b_catalog_store_product и обновляется общий остаток в b_catalog_product (поле QUANTITY).
Типы документов:
| Тип | Описание | Пример |
|---|---|---|
| A | Приход | Поступление товара от поставщика |
| S | Расход | Отгрузка заказа |
| M | Перемещение | Между складами |
| I | Инвентаризация | Пересчёт остатков |
Ручное создание документа расхода:
$doc = new \Bitrix\Catalog\Document\DocBuilder(); $doc->setDocType(\Bitrix\Catalog\StoreDocumentTable::TYPE_SALES_ORDERS); $doc->setStoreFrom(3); // склад отгрузки $doc->addItem($productId, $quantity); $result = $doc->save(); if ($result->isSuccess()) { \Bitrix\Catalog\Document\DocManager::conductDocument($result->getId()); } Интеграция со статусами заказов
Автоматическое списание со склада при смене статуса заказа настраивается через обработчик события OnOrderStatusChange. Стандартный механизм — настройка в «Магазин → Настройки → Склады»: для каждого статуса заказа можно задать автоматическое проведение складского документа. Но, как сказано выше, он не подходит для частичной отгрузки.
Синхронизация с 1С
При синхронизации остатков через CommerceML (bitrix:catalog.import.1c) обновления остатков идут через b_catalog_store_product напрямую, минуя документооборот. Это означает, что b_catalog_docs не содержит истории изменений из 1С — только операции, созданные внутри Битрикса. Если нужна полная история движения, синхронизация должна создавать документы, а не обновлять остатки напрямую. Мы реализуем интеграцию через CommerceML, которая гарантирует согласованность данных.
Типичные ошибки при настройке мультисклада
- Отсутствие индекса по STORE_ID в b_catalog_store_product — приводит к медленным запросам. Добавьте составной индекс (STORE_ID, PRODUCT_ID).
- Неправильное значение ALLOW_STORE_AMOUNT — покупатель не видит распределения по складам. Включите в настройках sale.order.ajax.
- Резервирование без указания склада в элементе заказа — весь товар резервируется с одного склада. Исправляется привязкой склада к заказу.
- Использование стандартного обработчика для частичных отгрузок — потеря остатков. Используйте кастомный обработчик.
Имея 7 лет опыта в разработке на Битриксе и более 50 проектов по складскому учёту, мы гарантируем стабильную работу системы. Закажите аудит складского учёта уже сегодня — оценим ваш проект и предложим оптимальное решение. Свяжитесь для консультации.