A customer places an order, pays electronically, waits for delivery — but the item is out of stock. Stock levels on the site haven't been updated for two days, and the product was sold in the meantime. Refund, negative review, lost customer.
According to our project data, automatic stock synchronization every 15 minutes reduces the risk of discrepancies by 95%. In one electronics store, we eliminated daily lost orders — from 10 to zero. With an average order value of 5,000 rubles, the monthly savings were significant.
Automated stock updates with scheduled synchronization solve this problem — provided they are configured correctly. We offer a turnkey solution: from analyzing the source to setting up monitoring. We can assess your project in one day — send us a description of your catalog and data source. Our engineer will propose the optimal architecture considering volumes and update frequency. Contact us for details.
Why performance matters when updating stock
Mass updating tens of thousands of items via the standard Bitrix API is slow. Each record triggers event handlers, cache recalculation, and availability checks. Update time per item can reach 3–5 seconds. Without optimization, the script may run for hours and risk overloading the server. For a catalog of 50,000 products, synchronization could be delayed up to 3 days.
Solving the performance problem
We use batch queries and disable events. For example, when updating 50,000+ items, a direct SQL query to b_catalog_store_product in batches of 500–1000 rows cuts time by 10x. Additionally, we disable handlers via \Bitrix\Catalog\ProductTable::disableEvents() and recalculate availability once after all writes. In one project, a catalog of 80,000 products updates in 3 minutes instead of 8 hours.
Data structure and API
The catalog module stores stock data in several tables: b_catalog_product (field QUANTITY), b_catalog_store_product (per-warehouse stock), and b_catalog_store (warehouse directory). If your site uses a single warehouse, update QUANTITY; if warehouse accounting is enabled, update b_catalog_store_product and Bitrix will recalculate total stock automatically.
Simple option — single warehouse:
\Bitrix\Catalog\ProductTable::update($productId, [
'QUANTITY' => $newQuantity,
]);
Warehouse accounting — multiple warehouses:
$existing = \Bitrix\Catalog\StoreProductTable::getList([
'filter' => ['PRODUCT_ID' => $productId, 'STORE_ID' => $storeId],
])->fetch();
if ($existing) {
\Bitrix\Catalog\StoreProductTable::update($existing['ID'], ['AMOUNT' => $newQuantity]);
} else {
\Bitrix\Catalog\StoreProductTable::add([
'PRODUCT_ID' => $productId,
'STORE_ID' => $storeId,
'AMOUNT' => $newQuantity,
]);
}
After updating per-warehouse stock, trigger overall quantity recalculation:
CCatalogProduct::QuantityTracer($productId);
Handling data discrepancies between source and site
Discrepancies are inevitable: supplier file didn't arrive, script failed, data structure changed. We set up monitoring that checks the last update time and alerts on anomalies — for example, if 80% of the catalog's stock suddenly goes to zero. We log counts of updated, skipped, and erroneous items. On failure, an engineer receives an alert via Telegram or email and restores the process within an hour.
Performance optimization for mass updates
Updating 50,000+ items one by one via API is too slow — 3–5 seconds per item due to event handlers and cache recalculations. Optimization:
- Batch UPDATE — direct SQL to update
b_catalog_store_productin batches of 500–1000 rows. - Disable events —
\Bitrix\Catalog\ProductTable::disableEvents()during mass updates. - Deferred recalculation — update all stock, then recalculate availability once and clear the cache.
Data formats and mapping
| Format | Parsing | Notes |
|---|---|---|
| CSV | fgetcsv() |
Simple but no typing — "10" and "10 pcs" need normalization |
| Excel (XLSX) | PhpSpreadsheet | Often contains multiple sheets, headers on row 2–3 |
| XML (CommerceML) | CommerceML | 1C standard, known structure |
| REST API | curl / Guzzle |
JSON response, pagination, authorization |
| FTP file | ftp_get() |
File appears at a specific time, needs retry |
The key task is to match the product identifier in the supplier's price list to the Bitrix catalog item. Options:
- By SKU — property
PROPERTY_ARTICLEorPROPERTY_SUPPLIER_SKU. Most reliable if SKUs are unique. - By
XML_ID— if the catalog was originally imported from the same source. - By barcode —
b_catalog_product_barcodetable. Reliable, but not all products have barcodes.
For mapping, we create an indexed correspondence table:
CREATE TABLE parser_product_map (
supplier_sku VARCHAR(100) NOT NULL,
product_id INT NOT NULL,
store_id INT DEFAULT 1,
PRIMARY KEY (supplier_sku, store_id),
INDEX idx_product (product_id)
);
Queries through this table are 10–50 times faster than searching by infoblock properties for each product.
Scheduling and handling zero stock
Update frequency depends on product turnover:
| Product type | Update frequency | Rationale |
|---|---|---|
| Fast-moving (electronics, groceries) | Every 15–30 min | Rapid turnover, high risk of overselling |
| Medium-moving (clothing, tools) | Every 1–2 hours | Balance of accuracy and load |
| Slow-moving (furniture, equipment) | 2–4 times daily | Low turnover |
# Update stock every 30 minutes
*/30 * * * * /usr/bin/php /home/bitrix/scripts/update_stock.php >> /var/log/stock_update.log 2>&1
For zero stock items, we apply one of three strategies:
- Deactivation (
ACTIVE = 'N') — product disappears from the site. Bad for SEO: page deindexed, positions lost. - Display with "Out of stock" label —
QUANTITY = 0,CAN_BUY_ZERO = 'N'. "Buy" button replaced with "Notify when available". Optimal. - Pre-order —
CAN_BUY_ZERO = 'Y'. Customer can place an order; product arrives with next shipment. Suitable for items with predictable delivery.
The strategy is set globally in the catalog module settings and can be overridden per product.
Monitoring
Stock update is a critical process. If the script fails or the supplier doesn't send a file, the catalog shows outdated data. Minimal monitoring includes:
- Check the time of the last successful update. If more than two intervals have passed, alert.
- Log counts of updated, skipped (not found in mapping), and erroneous items.
- Anomaly control: if 80% of the catalog's stock zeros out at once, it's likely a supplier file error, not a real sale.
What's included in the work
- Audit of current catalog and data sources: structure, volume, update frequency.
- Architecture design: mapping, batch queries, caching.
- Script development supporting CSV, Excel, XML, REST, FTP.
- Performance optimization: batch queries, event disabling, deferred recalculation.
- Cron scheduling and logging setup.
- Monitoring integration with alerts via Telegram or email.
- Documentation: data schema and update process.
- Administrator training: manual execution, log reading, failure recovery.
Experience and guarantees
Our team has over 5 years of 1C-Bitrix development experience. We have completed more than 50 integration projects, including 1C exchanges and online stores with catalogs exceeding 100,000 items. We provide a 3-month guarantee on correct synchronization operation after launch. Certified Bitrix specialists ensure compliance with all platform standards. Get an engineer consultation and project assessment in 1 day.
Checklist for successful integration
- Ensure supplier SKUs are unique and stable.
- Verify file folder (FTP) and cron log access rights.
- Set up monitoring from day one — don't postpone.
- Test zero stock handling during development.
- Document file format and mapping.
Contact us to start developing today and eliminate manual stock updates.