Покупатель оформляет заказ, оплачивает электроникой, ждёт доставку — а товара на складе нет. Остатки на сайте не обновлялись двое суток, и за это время позиция ушла. Возврат средств, негативный отзыв, потеря клиента.
По данным наших проектов, автоматическая синхронизация остатков каждые 15 минут снижает риск расхождений на 95%. В одном из магазинов электроники до настройки теряли до 10 заказов в день — после интеграции потери ушли в ноль. При среднем чеке в 5 000 руб. экономия составила значительную сумму в месяц.
Автоматическое обновление остатков и синхронизация остатков по расписанию решает эту проблему — при условии, что настроено правильно. Мы предлагаем решение под ключ: от анализа источника до настройки мониторинга. Оценить проект можно за один день — пришлите описание вашего каталога и источника данных. Инженер предложит оптимальную архитектуру с учётом объёмов и частоты обновления. Свяжитесь с нами для уточнения деталей.
Почему важна производительность при обновлении остатков?
Массовое обновление десятков тысяч позиций через стандартный 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-логам.
- Настройте мониторинг с первого дня — не откладывайте.
- Протестируйте обработку нулевых остатков на этапе разработки.
- Документируйте формат файлов и маппинг.
Закажите разработку уже сегодня и избавьтесь от ручного обновления остатков.