Синхронизация цен и остатков с маркетплейсами

Выгрузить каталог на маркетплейс — половина дела. Дальше цены и остатки должны обновляться сами, иначе магазин быстро уходит в оверселл и штрафы. Разбираем, как выстроить надёжную синхронизацию на стороне 1С-Битрикс.

Почему одноразовой выгрузки недостаточно

Первичный экспорт фида решает задачу «товар появился в карточке». Но цена и остаток — это динамические данные, которые меняются каждый час: приходят продажи на сайте, идут поставки из 1С, срабатывают акции. Если маркетплейс видит устаревший остаток, вы получаете два сценария, и оба плохие.

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

Поэтому синхронизация — это не разовое действие, а постоянный фоновый процесс. Задача интегратора на Битрикс — организовать его так, чтобы данные обновлялись достаточно часто, но без перегрузки сервера и без превышения лимитов API площадок.

Где в Битрикс лежат цены и остатки

Прежде чем что-то синхронизировать, нужно чётко понимать источник истины. В модуле catalog (Торговый каталог) цены и количество хранятся в отдельных таблицах, а не в самом инфоблоке товаров.

• Цены — таблица b_catalog_price, доступ через \Bitrix\Catalog\PriceTable. У товара может быть несколько типов цен (базовая, оптовая, для маркетплейса).
• Остатки — при включённом складском учёте данные лежат в b_catalog_store_product (\Bitrix\Catalog\StoreProductTable) в разрезе складов; итоговое поле QUANTITY хранится в b_catalog_product.

Для торговых предложений (SKU, размер/цвет) остатки и цены хранятся у каждого предложения отдельно — на маркетплейс уходит именно предложение, привязанное к артикулу площадки.

Как площадки принимают обновления

У каждого маркетплейса свой механизм приёма цен и остатков, и это определяет архитектуру синхронизации.

Важное различие: YML-фид маркетплейс забирает сам по расписанию, а API вы вызываете сами и получаете подтверждение. Для остатков почти всегда предпочтителен API — он даёт частоту обновления в минутах, тогда как перечитывание фида площадка делает раз в несколько часов.

Регулярный запуск: агенты и cron

Синхронизацию запускают по расписанию. В Битрикс есть два штатных механизма, и выбор между ними принципиален.

• Агенты (CAgent) — привязаны к посещениям сайта или к hit'у cron. Просты в подключении, но при настройке «на хитах» работают нестабильно: нет трафика — нет запуска.
• Задание cron на уровне сервера — вызывает /bitrix/php_interface/cron/*.php или консольный скрипт. Надёжнее для критичных остатков: расписание не зависит от посетителей.

Рекомендуемая схема — вынести агенты на cron (константа define('BX_CRON', true) и запуск cron_events.php), а сам скрипт синхронизации сделать отдельным заданием с нужной частотой.

Отправляем только изменения

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

1. Ловим факт изменения. Для остатков это событие OnCatalogStoreProductUpdate либо OnSaleOrderSaved (списание при заказе), для цен — OnPriceUpdate. Обработчик помечает товар «грязным» в служебной таблице очереди.
2. По расписанию скрипт выбирает из очереди изменённые SKU, собирает актуальные значения и отправляет их пачкой в API площадки.
3. После успешного ответа помечаем позиции обработанными и логируем результат.

Такая очередь резко снижает объём трафика к API и позволяет обновлять остатки почти в реальном времени, а полный «сверочный» прогон запускать раз в сутки — чтобы подстраховаться от пропущенных событий.

Склады, резервы и маппинг цен

Самая частая причина оверселла — неправильный расчёт доступного количества. На маркетплейс нельзя слепо отдавать поле QUANTITY.

• Резервы. Учитывайте QUANTITY_RESERVED — товар, уже зарезервированный под заказы сайта. Доступный остаток = количество − резерв.
• Разделение складов. Если под маркетплейс выделен отдельный склад (модель FBS), в API уходит остаток именно этого склада, а не общий по всем магазинам.
• Страховой запас. Многие продавцы отдают на площадку остаток минус буфер (например, −2 шт.), чтобы компенсировать задержку синхронизации при пиковых продажах.

Для цен настраивается маппинг типа цены: на маркетплейс часто уходит не базовая розничная цена, а отдельный тип (с учётом комиссии площадки и логистики). В Битрикс это удобно решается отдельным типом цен в модуле catalog плюс правило пересчёта в скрипте синхронизации.

Логи, мониторинг и обработка ошибок

Синхронизация обязана быть наблюдаемой. Молчаливо упавший агент — это дни продаж с неверными остатками, о которых вы узнаете из штрафа.

• Логирование каждого запроса — какие SKU отправлены, код ответа API, тело ошибки. Пишите в отдельную таблицу или в /bitrix/php_interface/log/.
• Ретраи. При ошибке 429 (rate limit) или 5xx позиция возвращается в очередь и переотправляется позже, а не теряется.
• Алерты. Если процент отклонённых позиций превысил порог или агент не отработал N часов — уведомление на почту или в мессенджер.

Итог

Надёжная синхронизация цен и остатков на 1С-Битрикс держится на нескольких вещах: корректный источник данных (обычно после обмена с 1С), учёт резервов и складов при расчёте доступного количества, отправка только дельты по событиям, запуск через cron с соблюдением лимитов API и обязательный мониторинг с ретраями. Собранная так система работает годами без оверселла и ручного вмешательства.

Мы в B2Bsite проектируем такие интеграции под конкретную связку «1С — Битрикс — маркетплейсы»: настраиваем очередь изменений, маппинг цен и складов, логирование и сверку. Если нужна стабильная синхронизация без штрафов площадок — поможем спроектировать и внедрить её под ваш каталог.