Setting Up a Stock Arrival Trigger: Automatic Notification in 1C-Bitrix
Imagine: a product goes out of stock, dozens of users click "Notify me when back in stock," the warehouse is restocked, but nobody receives an email. The cause is a missing link between the restock event and the waiting list. In this article, we'll break down how to set up a stock arrival trigger in 1C-Bitrix: from a simple catalog to multi-warehouse accounting with 1C integration. We have implemented such mechanisms on 30+ projects—we'll share typical pitfalls and optimal solutions. According to the official Bitrix documentation, the OnProductUpdate event is a key tool for tracking stock changes. But it alone is not enough: you need to properly handle subscriptions and multi-warehouse logic. Our experience shows that a correct implementation reduces response time to stock arrival by a factor of 3 compared to manual checking.
How Warehouse Accounting Works in Bitrix
In Bitrix, product quantities live in two places depending on the configuration. In a simple catalog (without warehouse accounting), the CATALOG_QUANTITY field in the b_catalog_product table is used. It is updated directly via CCatalogProduct::Update() or through 1C exchange. In multi-warehouse accounting (catalog module + warehouses), data is stored in the b_catalog_store_product table with fields PRODUCT_ID, STORE_ID, AMOUNT. The total quantity is aggregated. During 1C exchange via CommerceML, data is written to b_catalog_store_product. The standard handler for stock changes is OnProductUpdate in the catalog module. It fires whenever a record in b_catalog_product changes, including quantity. However, for multi-warehouse accounting, this is insufficient—the event does not track changes per individual warehouse. Comparison is straightforward: the OnProductUpdate handler works instantly but only for the total stock, while an agent (checking every 5 minutes) covers all warehouses but with a delay.
Here’s a basic handler example:
AddEventHandler('catalog', 'OnProductUpdate', function($id, $fields) {
if (isset($fields['QUANTITY']) && $fields['QUANTITY'] > 0) {
// Product arrived in stock—was zero
checkAndNotifyWaitlist($id);
}
});
Problem: OnProductUpdate fires on any product change, not just restock. To filter specifically for the "arrived from zero" event, you need to compare the previous value. Before the PHP event, data is still in the DB, so read the old value in OnBeforeProductUpdate:
AddEventHandler('catalog', 'OnBeforeProductUpdate', function($id, &$fields) {
$old = \Bitrix\Catalog\ProductTable::getByPrimary($id, ['select' => ['QUANTITY']])->fetch();
$fields['_OLD_QUANTITY'] = (float)($old['QUANTITY'] ?? 0);
});
Why the Standard Handler Is Not Suitable for Multi-Warehouse Accounting
With multi-warehouse accounting, the OnProductUpdate event does not fire when b_catalog_store_product changes. For warehouse operations, you need to subscribe to deeper-level events in the catalog module—either use a hook after a warehouse document is written via \Bitrix\Catalog\Document\DocumentTable. An alternative approach: an agent that checks b_catalog_store_product every 5 minutes for non‑zero quantities of products on the waiting list. Less elegant, but works more reliably with non‑standard stock update schemes (e.g., direct UPDATE via a 1C connector). Based on our experience, an agent handles the load in 90% of cases, while a document handler reacts 10 times faster but requires more careful implementation.
Comparison of Approaches: Agent vs Document Handler
| Parameter | Agent | Document Handler |
|---|---|---|
| Response to changes | Up to 5 minute delay | Instant |
| Database load | Periodic queries | Only on changes |
| Implementation complexity | Low | Medium |
| Reliability during bulk updates | High | High |
| Recommendation | For non‑standard updates | For standard operations |
How to Store Subscriptions for Arrival Notifications
The catalog module has no built-in "notify when back in stock" mechanism. You need a custom table:
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)
);
The form on the site writes to this table. The unique key (product_id, email) protects against duplicates on repeated subscriptions.
Restock Handler
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']}"
);
}
}
Comparison of Approaches: Simple Catalog vs Multi-Warehouse Accounting
| Parameter | Simple Catalog | Multi-Warehouse Accounting |
|---|---|---|
| Stock change event | OnProductUpdate |
Requires agent or document handler |
| Stock table | b_catalog_product |
b_catalog_store_product |
| Implementation complexity | Low | Medium |
| Setup time | 1-2 days | 3-5 days |
| Reliability during bulk updates | High | Requires additional synchronization |
What's Included: Deliverables
- Development and installation of
OnBeforeProductUpdateandOnProductUpdatehandlers with "0 → N" transition check. - Creation of
bl_stock_notifytable and integration of the subscription form on the site. - Configuration of the
STOCK_ARRIVEDemail template in the admin panel. - For multi-warehouse configurations: implementation of an agent or warehouse document handler.
- Logic for partial restock: strategy selection (notify all or in sequence).
- Access documentation and testing on a staging environment.
- 14-day support after launch.
Process
- Analysis: study your current Bitrix configuration, 1C exchange scheme, database load.
- Design: select the optimal method (handlers or agent), agree on notification queue logic.
- Implementation: write code, create SQL table, configure email events.
- Testing: verify on a catalog copy, simulate stock arrival, track email sending.
- Deployment and monitoring: move to production, log first triggers.
Typical Mistakes in DIY Setup
- Incorrect event filtering: sending notifications on any product change, not just when it appears from zero.
- Missing unique key in the subscription table—duplicate emails.
- Ignoring multi-warehouse architecture—notifications fail when stock is replenished at a specific warehouse.
- No handling of partial restock: if fewer units arrive than subscribers.
These issues are easily avoided by following the described methodology.
Timelines and Cost
Estimated timelines are from 2 to 10 business days depending on complexity. The cost is calculated individually after analyzing your configuration. Contact us for a preliminary evaluation—we guarantee transparent results and post-implementation support. Get a consultation—we will find the optimal solution for your accounting scheme. Our experience in this area covers over 30 Bitrix notification automation projects.