Автоматизация уведомлений о поступлении товара: настройка в 1С-Битрикс

Настройка триггера поступления товара на склад: автоматическое уведомление в 1С-Битрикс

Представьте: товар закончился, десятки пользователей нажали «Уведомить о поступлении», склад пополнился, но никто не получил письма. Причина — отсутствие связи между событием пополнения склада и списком ожидающих. В этой статье разберём, как настроить триггер поступления товара на склад в 1С-Битрикс: от простого каталога до многоскладского учёта с интеграцией 1С. Мы реализовали такие механизмы на 30+ проектах — расскажем о типичных ошибках и оптимальных решениях. По данным официальной документации Битрикс, событие OnProductUpdate — ключевой инструмент для отслеживания изменений остатков. Но его одного недостаточно: нужно грамотно обработать подписки и многоскладскую логику. Наш опыт показывает: правильная реализация сокращает время реакции на поступление товара в 3 раза по сравнению с ручной проверкой.

Как работает складской учёт в Битрикс?

В Битрикс остатки товаров живут в двух местах в зависимости от конфигурации. В простом каталоге (без складского учёта) используется поле CATALOG_QUANTITY в таблице b_catalog_product. Обновляется напрямую через CCatalogProduct::Update() или через обмен с 1С. В многоскладском учёте (модуль catalog + склады) данные хранятся в таблице b_catalog_store_product с полями PRODUCT_ID, STORE_ID, AMOUNT. Общий остаток агрегируется. При обмене с 1С через CommerceML данные пишутся в b_catalog_store_product. Стандартный обработчик изменения остатка — OnProductUpdate в модуле catalog. Он срабатывает при любом изменении записи в b_catalog_product, включая количество. Однако для многоскладского учёта этого недостаточно — событие не отслеживает изменения по отдельным складам. Сравнение простое: обработчик OnProductUpdate работает мгновенно, но только для общего остатка, а агент (проверка каждые 5 минут) охватывает все склады, но с задержкой.

Вот пример базового обработчика:

AddEventHandler('catalog', 'OnProductUpdate', function($id, $fields) { if (isset($fields['QUANTITY']) && $fields['QUANTITY'] > 0) { // Товар поступил на склад — была нулевая позиция checkAndNotifyWaitlist($id); } }); 

Проблема: OnProductUpdate срабатывает при любом изменении продукта, не только при пополнении склада. Чтобы отфильтровать именно событие «появился из нуля», нужно сравнивать предыдущее значение. До PHP-события данные ещё в БД, поэтому читаем старое значение в OnBeforeProductUpdate:

AddEventHandler('catalog', 'OnBeforeProductUpdate', function($id, &$fields) { $old = \Bitrix\Catalog\ProductTable::getByPrimary($id, ['select' => ['QUANTITY']])->fetch(); $fields['_OLD_QUANTITY'] = (float)($old['QUANTITY'] ?? 0); }); 

Почему стандартный обработчик не подходит для многоскладского учёта?

При многоскладском учёте событие OnProductUpdate не срабатывает при изменении b_catalog_store_product. Для складских операций нужно подписаться на события модуля catalog более глубокого уровня — либо использовать хук после записи документа складского учёта через \Bitrix\Catalog\Document\DocumentTable. Альтернативный подход: агент, который каждые 5 минут проверяет b_catalog_store_product на появление ненулевых остатков по товарам из листа ожидания. Менее элегантно, но работает стабильнее при нестандартных схемах обновления остатков (например, при прямом UPDATE через 1С-коннектор). По нашему опыту, агент справляется с нагрузкой в 90% случаев, а обработчик документов реагирует в 10 раз быстрее, но требует более аккуратной реализации.

Сравнение подходов: агент vs обработчик документов

Как хранить подписки на поступление?

Модуль catalog не имеет встроенного механизма «уведомить о поступлении». Нужна собственная таблица:

CREATE TABLE bl_stock_notify ( id SERIAL PRIMARY KEY, product_id INT NOT NULL, user_id INT, email VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), notified_at TIMESTAMP, UNIQUE (product_id, email) ); 

Форма на сайте пишет в эту таблицу. Уникальный ключ (product_id, email) защищает от дублей при повторных подписках.

Обработчик пополнения

function checkAndNotifyWaitlist(int $productId): void { $connection = \Bitrix\Main\Application::getConnection(); $waitlist = $connection->query( "SELECT * FROM bl_stock_notify WHERE product_id = {$productId} AND notified_at IS NULL" )->fetchAll(); if (empty($waitlist)) { return; } $product = \CIBlockElement::GetByID($productId)->GetNextElement(); $name = $product->GetField('NAME'); $url = $product->GetField('DETAIL_PAGE_URL'); foreach ($waitlist as $row) { \Bitrix\Main\Mail\Event::send([ 'EVENT_NAME' => 'STOCK_ARRIVED', 'LID' => SITE_ID, 'C_FIELDS' => [ 'EMAIL' => $row['email'], 'PRODUCT_NAME' => $name, 'PRODUCT_URL' => 'https://' . $_SERVER['SERVER_NAME'] . $url, ], ]); $connection->queryExecute( "UPDATE bl_stock_notify SET notified_at = NOW() WHERE id = {$row['id']}" ); } } 

Сравнение подходов: простой каталог vs многоскладской учёт

Что входит в работу: deliverables

• Разработка и установка обработчиков OnBeforeProductUpdate и OnProductUpdate с проверкой перехода «0 → N».
• Создание таблицы bl_stock_notify и интеграция формы подписки на сайте.
• Настройка почтового шаблона STOCK_ARRIVED в административном разделе.
• Для многоскладской конфигурации — реализация агента или обработчика документов склада.
• Логика частичного поступления: выбор стратегии (уведомить всех или по очереди).
• Документация по доступам и тестирование на staging-окружении.
• Поддержка в течение 14 дней после запуска.

Процесс работы

1. Аналитика: изучаем текущую конфигурацию Битрикс, схему обмена с 1С, нагрузку на базу.
2. Проектирование: выбираем оптимальный метод (обработчики или агент), согласуем логику очереди уведомлений.
3. Реализация: пишем код, создаём SQL-таблицу, настраиваем почтовые события.
4. Тестирование: проверяем на копии каталога, имитируем поступление товара, отслеживаем отправку писем.
5. Деплой и мониторинг: переносим на боевой сервер, логируем первые срабатывания.