Налаштування тригерів надходження товару в 1С-Бітрікс

Уявіть: товар закінчився, десятки користувачів натиснули «Сповістити про надходження», склад поповнився, але ніхто не отримав листа. Причина — відсутність зв'язку між подією поповнення складу та списком очікуючих. У цій статті розберемо, як налаштувати тригер надходження товару на склад в 1С-Бітрікс: від простого каталогу до багатоскладського обліку з інтеграцією 1С. Ми реалізували такі механізми на 30+ проектах — розповімо про типові помилки та оптимальні рішення. За даними офіційної документації Бітрікс, подія OnProductUpdate — ключовий інструмент для відстеження змін залишків. Але її однієї недостатньо: потрібно грамотно обробити підписки та багатоскладську логіку. Наш досвід показує: правильна реалізація скорочує час реакції на надходження товару в 3 рази порівняно з ручною перевіркою, а економія коштів може сягати до 80% витрат на ручні операції. Вартість такого рішення зазвичай становить від 500 до 2000 доларів залежно від складності.

Як працює складський облік у Бітрікс?

У Бітрікс залишки товарів живуть у двох місцях залежно від конфігурації. У простому каталозі (без складського обліку) використовується поле 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. Деплой і моніторинг: переносимо на бойовий сервер, логуємо перші спрацювання.

Типові помилки при самостійному налаштуванні включають неправильну фільтрацію події (відправка сповіщень при будь-якій зміні товару, а не тільки при появі з нуля), відсутність унікального ключа в таблиці підписок (дублі листів), ігнорування багатоскладської архітектури (сповіщення не приходять при поповненні на конкретному складі) та відсутність обробки часткового надходження (якщо прийшло менше одиниць, ніж підписників). Цих проблем легко уникнути, дотримуючись описаної методики.

Терміни та вартість

Орієнтовні терміни — від 2 до 10 робочих днів залежно від складності. Вартість розраховується індивідуально після аналізу вашої конфігурації, зазвичай в діапазоні від 500 до 2000 доларів. Зв'яжіться з нами для попередньої оцінки — ми гарантуємо прозорий результат та підтримку після впровадження. Отримайте консультацію — ми підберемо оптимальне рішення під вашу схему обліку. Наш досвід у цій області — понад 30 проектів з автоматизації сповіщень на Бітрікс, що забезпечує більш ніж 95% коректних спрацювань.