Покупець оформлює замовлення, оплачує електронікою, чекає доставку — а товару на складі немає. Затримка всього на дві доби — і втрачаємо клієнта. Ми, команда TrueTech, знаємо, як цьому запобігти. Наша синхронізація залишків працює вдвічі швидше за стандартні рішення Бітрікс, оновлюючи дані кожні 15 хвилин. В одному з проєктів ми скоротили час оновлення каталогу на 80 000 товарів з 8 годин до 3 хвилин — це в 160 разів швидше! Економія для клієнта склала понад 50 000 грн на місяць завдяки зменшенню втрачених замовлень.
За даними наших проєктів, автоматична синхронізація залишків кожні 15 хвилин знижує ризик розбіжностей на 95%. В одному з магазинів електроніки до налаштування втрачали до 10 замовлень на день — після інтеграції втрати пішли в нуль. При середньому чеку в 5000 грн економія склала значну суму на місяць.
Автоматичне оновлення залишків і синхронізація залишків за розкладом вирішує цю проблему — за умови, що налаштовано правильно. Ми пропонуємо рішення під ключ: від аналізу джерела до налаштування моніторингу. Оцінити проєкт можна за один день — надішліть опис вашого каталогу та джерела даних. Інженер запропонує оптимальну архітектуру з урахуванням обсягів і частоти оновлення. Зв'яжіться з нами для уточнення деталей.
Чому важлива продуктивність при оновленні залишків?
Масове оновлення десятків тисяч позицій через стандартний API Бітрікс — повільний шлях. На кожен запис спрацьовують обробники подій, перерахунок кешів та доступності. Час оновлення однієї позиції може досягати 3–5 секунд. Без оптимізації скрипт виконуватиметься годинами, і ви ризикуєте перевантажити сервер. Для каталогу з 50 000 товарів це призведе до простою синхронізації до 3 діб.
Як вирішити проблему продуктивності?
Використовуємо батчеві запити та відключення подій. Наприклад, при оновленні 50 000+ позицій прямий SQL-запит до b_catalog_store_product пакетами по 500–1000 рядків скорочує час у 10 разів. Додатково відключаємо обробники через \Bitrix\Catalog\ProductTable::disableEvents() і перераховуємо доступність одноразово після всіх записів. В одному з проєктів каталог з 80 000 товарів оновлюється за 3 хвилини замість 8 годин.
Структура даних та API
Модуль catalog зберігає дані про наявність у кількох таблицях: b_catalog_product (поле QUANTITY), b_catalog_store_product (залишки по складах), b_catalog_store (довідник складів). Якщо на сайті один склад — оновлюйте QUANTITY; якщо включено складський облік — оновлюйте b_catalog_store_product, а Бітрікс перерахує загальний залишок автоматично.
Простий варіант — один склад:
\Bitrix\Catalog\ProductTable::update($productId, [
'QUANTITY' => $newQuantity,
]);
Складський облік — кілька складів:
$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,
]);
}
Після оновлення залишків по складах викличте перерахунок загальної кількості:
CCatalogProduct::QuantityTracer($productId);
Обробка розбіжностей даних між джерелом і сайтом
Розбіжності неминучі: файл постачальника не прийшов, скрипт впав, структура даних змінилася. Ми налаштовуємо моніторинг, який перевіряє час останнього оновлення та сигналізує про аномалії — наприклад, якщо раптом обнулилися залишки по 80% каталогу. Логується кількість оновлених, пропущених та помилкових позицій. При збої інженер отримує сповіщення в Telegram або email і відновлює процес протягом години.
Оптимізація продуктивності при масових оновленнях
При оновленні 50 000+ позицій поелементне оновлення через API надто повільне — 3–5 секунд на товар через обробники подій та перерахунок кешів. Оптимізація:
- Батчевий UPDATE — прямий SQL-запит для оновлення
b_catalog_store_productпакетами по 500–1000 рядків. - Відключення подій —
\Bitrix\Catalog\ProductTable::disableEvents()на час масового оновлення. - Відкладений перерахунок — оновити всі залишки, потім одноразово перерахувати доступність і скинути кеш.
Формати даних та мапінг
| Формат | Парсинг | Особливості |
|---|---|---|
| CSV | fgetcsv() |
Простий, але без типізації — «10» і «10 шт.» потрібно нормалізувати |
| Excel (XLSX) | PhpSpreadsheet | Часто містить кілька аркушів, заголовки на 2–3 рядку |
| XML (CommerceML) | CommerceML | Стандарт 1С, структура відома заздалегідь |
| REST API | curl / Guzzle |
JSON-відповідь, пагінація, авторизація |
| FTP-файл | ftp_get() |
Файл з'являється в певний час, потрібен retry |
Ключове завдання — зіставити ідентифікатор товару в прайсі постачальника з елементом каталогу Бітрікс. Варіанти:
- За артикулом — властивість
PROPERTY_ARTICLEабоPROPERTY_SUPPLIER_SKU. Найнадійніший за умови, що артикули унікальні. - За
XML_ID— якщо каталог спочатку імпортовано з того ж джерела. - За штрихкодом — таблиця
b_catalog_product_barcode. Надійно, але штрихкоди є не у всіх товарів.
Для мапінгу створіть індексовану таблицю відповідностей:
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)
);
Запит через цю таблицю в 10–50 разів швидше, ніж пошук за властивостями інфоблоку на кожен товар.
Налаштування розкладу та обробка нульових залишків
Частота оновлення залежить від оборотності товару:
| Тип товару | Частота оновлення | Обґрунтування |
|---|---|---|
| Ходовий (електроніка, продукти) | Кожні 15–30 хв | Швидка оборотність, високий ризик пересорту |
| Середній (одяг, інструмент) | Кожні 1–2 години | Баланс актуальності та навантаження |
| Повільний (меблі, обладнання) | 2–4 рази на добу | Низька оборотність |
# Оновлення залишків кожні 30 хвилин
*/30 * * * * /usr/bin/php /home/bitrix/scripts/update_stock.php >> /var/log/stock_update.log 2>&1
При нульових залишках товару застосовуються три стратегії поведінки:
- Деактивація (
ACTIVE = 'N') — товар зникає з сайту. Погано для SEO: сторінка перестає індексуватися, втрачаються позиції. - Показ з позначкою «Немає в наявності» —
QUANTITY = 0,CAN_BUY_ZERO = 'N'. Кнопка «Купити» замінюється на «Повідомити про надходження». Оптимальний варіант. - Передзамовлення —
CAN_BUY_ZERO = 'Y'. Покупець може оформити замовлення, товар прийде з найближчою поставкою. Підходить для товарів з передбачуваним терміном поставки.
Стратегія задається глобально в налаштуваннях модуля catalog і може бути перевизначена для конкретного товару.
Моніторинг
Оновлення залишків — критичний процес. Якщо скрипт впав або постачальник не віддав файл — каталог показує застарілі дані. Мінімальний моніторинг:
- Перевірка часу останнього успішного оновлення. Якщо минуло більше двох інтервалів — сповіщення.
- Логування кількості оновлених, пропущених (не знайдено в мапінгу) та помилкових позицій.
- Контроль аномалій: якщо раптом обнулилися залишки по 80% каталогу — швидше за все, помилка у файлі постачальника, а не реальний розпродаж.
Що входить у роботу
- Аудит поточного каталогу та джерел даних: структура, обсяг, частота надходження.
- Проєктування архітектури: мапінг, батчеві запити, кешування.
- Розробка скриптів імпорту з підтримкою CSV, Excel, XML, REST, FTP.
- Оптимізація продуктивності: батчеві запити, відключення подій, відкладений перерахунок.
- Налаштування cron-розкладу та логування.
- Інтеграція моніторингу зі сповіщеннями через Telegram або email.
- Документування схеми даних та процесу оновлення.
- Навчання адміністраторів: ручний запуск, читання логів, дії при збої.
Досвід і гарантії
Наша команда має досвід розробки на 1С-Бітрікс понад 5 років. Виконано понад 50 проєктів з інтеграції зовнішніх систем, включаючи обмін з 1С, інтернет-магазини з каталогами >100 000 товарів. Надаємо гарантію на коректну роботу синхронізації протягом 3 місяців після запуску. Сертифіковані фахівці Бітрікс забезпечують дотримання всіх стандартів платформи. Отримайте консультацію інженера та оцінку проєкту за 1 день.
Чек-лист для успішної інтеграції
- Переконайтеся, що артикули унікальні та стабільні у постачальника.
- Перевірте права доступу до папки з файлами (FTP) та cron-логами.
- Налаштуйте моніторинг з першого дня — не відкладайте.
- Протестуйте обробку нульових залишків на етапі розробки.
- Документуйте формат файлів та мапінг.
Замовте розробку вже сьогодні та позбудьтеся ручного оновлення залишків.