Автоматическая синхронизация остатков: настройка в 1С-Битрикс

Покупатель оформляет заказ, оплачивает электроникой, ждёт доставку — а товара на складе нет. Остатки на сайте не обновлялись двое суток, и за это время позиция ушла. Возврат средств, негативный отзыв, потеря клиента.

По данным наших проектов, автоматическая синхронизация остатков каждые 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() на время массового обновления.
• Отложенный пересчёт — обновить все остатки, затем однократно пересчитать доступность и сбросить кеш.

Форматы данных и маппинг

Ключевая задача — сопоставить идентификатор товара в прайсе поставщика с элементом каталога Битрикс. Варианты:

• По артикулу — свойство 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 раз быстрее, чем поиск по свойствам инфоблока на каждый товар.

Настройка расписания и обработка нулевых остатков

Частота обновления зависит от оборачиваемости товара:

# Обновление остатков каждые 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% каталога — скорее всего, ошибка в файле поставщика, а не реальная распродажа.

Что входит в работу

1. Аудит текущего каталога и источников данных: структура, объём, частота поступления.
2. Проектирование архитектуры: маппинг, батчевые запросы, кэширование.
3. Разработка скриптов импорта с поддержкой CSV, Excel, XML, REST, FTP.
4. Оптимизация производительности: батчевые запросы, отключение событий, отложенный пересчёт.
5. Настройка cron-расписания и логирования.
6. Интеграция мониторинга с алертами через Telegram или email.
7. Документирование схемы данных и процесса обновления.
8. Обучение администраторов: ручной запуск, чтение логов, действия при сбое.

Опыт и гарантии

Наша команда имеет опыт разработки на 1С-Битрикс более 5 лет. Выполнено свыше 50 проектов по интеграции внешних систем, включая обмен с 1С, интернет-магазины с каталогами >100 000 товаров. Предоставляем гарантию на корректную работу синхронизации в течение 3 месяцев после запуска. Сертифицированные специалисты Битрикс обеспечивают соблюдение всех стандартов платформы. Получите консультацию инженера и оценку проекта за 1 день.

Закажите разработку уже сегодня и избавьтесь от ручного обновления остатков.