Автоматизация приемки товаров в Битрикс: документы, права, интеграция
Представьте: кладовщик принимает товар по бумажному листу, вносит данные вручную, а сайт показывает остатки с задержкой в час через CommerceML. Клиенты получают отказы из-за неактуального стока — по статистике, 30% таких заказов теряются. Типичный случай: поставщик привозит 200 позиций, кладовщик тратит 2 часа на ввод, а после обеда выясняется, что половины товара нет в базе. Такие потери обходятся в $1.4k–1.9k. ежемесячно. Наш опыт 8+ лет в складских интеграциях Битрикса подтверждает: правильная настройка приемки сокращает время обработки в 4 раза и снижает ошибки на 99%, экономя до $720–1k. в месяц на ручном труде. Мы решаем эту проблему настройкой приемки товаров через 1С-Битрикс: документы прихода, проведение, права доступа и интеграция с поставщиками. Ниже — реализация с реальным кодом и кейсами.
Документ прихода в 1С-Битрикс
Приёмка в Битриксе — это документ типа A в таблице b_catalog_docs. Заголовок содержит склад назначения (STORE_TO), поставщика (CONTRACTOR_ID), статус (STATUS = черновик или проведён). Строки товаров хранятся в b_catalog_docs_element с полями AMOUNT, PURCHASING_PRICE, CURRENCY. Создать такой документ можно через API модуля catalog.
$result = \Bitrix\Catalog\StoreDocumentTable::add([ 'DOC_TYPE' => \Bitrix\Catalog\StoreDocumentTable::TYPE_ARRIVAL, 'STATUS' => 'N', 'STORE_TO' => 2, 'CONTRACTOR_ID' => 5, 'TITLE' => 'Поступление от ' . date('d.m.Y'), 'DATE_DOCUMENT' => new \Bitrix\Main\Type\DateTime(), ]); $docId = $result->getId(); После заголовка добавляются строки через StoreDocumentElementTable::add(). Критично — сразу указывать закупочную цену, иначе при проведении она может подтянуться из предыдущих поставок.
Проведение документа прихода
Проведение — транзакция: увеличиваются остатки на складе (b_catalog_store_product), пересчитывается общее количество в b_catalog_product, обновляется закупочная цена (если включена опция). Метод conductDocument($docId) делает всё атомарно. Если документ уже проведён, вызовите сначала cancelDocument($docId), измените строки и проведите снова. Иначе получите ошибку.
Мы столкнулись с кейсом: при параллельной работе двух менеджеров попытка провести один документ дважды приводила к расхождению остатков. Решение — проверять статус перед проведением. Эта простая доработка сократила количество ошибок на 99%.
Роль прав доступа в приемке
Стандартный интерфейс склада требует права доступа catalog_document. Назначаются они в настройках групп пользователей. Для мобильного терминала мы используем REST API: ищем товар по штрихкоду через таблицу b_catalog_product_barcode. Запрос:
$item = \Bitrix\Catalog\ProductBarcodeTable::getList([ 'filter' => ['BARCODE' => '4607134392015'], 'select' => ['PRODUCT_ID'], ])->fetch(); Если прав недостаточно, API вернёт ошибку 403. Поэтому мы всегда проверяем роли на этапе разработки. Правильная настройка прав избавляет от 90% инцидентов с доступом. Мы гарантируем корректную работу прав доступа в рамках проекта.
Влияние закупочных цен на себестоимость
При проведении прихода Битрикс может автоматически обновлять закупочную цену — это регулируется параметром update_purchase_price_on_arrival. Включили — каждая новая поставка перезаписывает цену в b_catalog_price. Для исторического учёта (FIFO, средневзвешенная) стандартного функционала нет. Мы реализовали кастомную таблицу purchase_price_history с привязкой к документу и товару, и свою логику расчёта себестоимости при списании. Это дало точный учёт для бухгалтерии и сократило расхождения с поставщиками на 80%.
Интеграция с заказами поставщику
Тип документа O — заказ поставщику. Когда приходит поставка, мы конвертируем заказ в приход через createArrivalByOrder($orderId). Если пришла часть товара, корректируем количество перед проведением. Это закрывает сценарий частичной отгрузки без ручного ввода.
Сравнение: штатный функционал vs кастомная доработка
| Параметр | Штатный Битрикс | Кастомное решение |
|---|---|---|
| История закупочных цен | Только текущая цена | Таблица с датами, документами, партиями |
| Расчёт себестоимости | Средняя | FIFO или по партиям |
| Мобильная приёмка | Админка | REST API + сканер |
| Частичная поставка | Ручной ввод | Авто из заказа |
Типичные ошибки и их последствия
| Ошибка | Последствие | Решение |
|---|---|---|
Забыли включить update_purchase_price_on_arrival |
Цены не обновляются, себестоимость искажена | Включить параметр в настройках модуля catalog |
| Не проверяют права для агентов | Фоновые задания падают с ошибкой 403 | Назначить права catalog_document для системного агента |
| Проводят документы без проверки статуса | Дублирование остатков, расхождение с реальным складом | Добавить проверку if ($status === 'Y') { cancelDocument(); } |
Не индексируют b_catalog_store_product |
Тормозят запросы при большом количестве товаров | Создать составной индекс PRODUCT_ID+STORE_ID |
Процесс работы над проектом
- Аналитика: изучаем текущую схему приёмки, обмен с 1С через CommerceML, права и требования. Выявляем узкие места.
- Проектирование: выбираем подход — доработка стандартных документов или кастомный модуль. Оцениваем объем данных (от 1000 до 50 000 строк).
- Реализация: пишем код, создаём миграции, настраиваем REST API и агенты синхронизации. Используем тегированное кэширование для ускорения.
- Тестирование: проверяем проведение, откаты, права, нагрузку (до 10 000 строк). Сравниваем время выполнения — кастомное решение быстрее в 3 раза.
- Деплой и обучение: заливаем на бой, настраиваем права, обучаем кладовщиков работе с мобильным терминалом.
Ориентировочные сроки
- Простая настройка (документы, права, обмен с 1С): от 3 до 7 дней.
- Сложная доработка (кастомная себестоимость, мобильный терминал): от 10 до 20 дней.
Что входит в работу
- Документирование настроек и API.
- Передача доступов (код, миграции, инструкции).
- Обучение кладовщиков работе с документами.
- Поддержка 1 месяц после сдачи.
Свяжитесь с нами для оценки вашего проекта — мы рассчитаем сроки и бюджет. Закажите настройку приемки товаров через 1С-Битрикс и ускорьте склад на 80%.