Ошибки синхронизации остатков: почему данные на маркетплейсах запаздывают

Пока они проходят, покупатель может оформить заказ на товар, которого уже нет на складе.

Для продавца на FBS это окно оверселлинга: остаток в 1С или CRM уже обнулился, а на маркетплейсе товар еще доступен. Отмена заказа может повлечь санкции площадки, а разбор причин часто начинается с поиска ошибки в интеграции. Однако сбой не обязательно находится в коде: часть задержки создают лимиты API и обработка данных на стороне самого маркетплейса.

Анатомия окна оверселлинга

Время между фактическим изменением остатка и его отображением на витрине складывается из трех компонентов:

1. Интервал синхронизации учетной системы. 1С или CRM проверяет изменения по расписанию и отправляет их не обязательно в момент продажи.

2. Прием запроса API. Площадка ограничивает частоту обращений и объем данных в одном запросе. Если лимит достигнут, обновление придется отложить или повторить.

3. Обработка и публикация на витрине. Даже принятые данные могут появиться в карточке не сразу.

Из-за этого ответ API со статусом успешного приема не всегда означает, что покупатель уже видит новое количество. Это две разные стадии: запрос принят и данные опубликованы. Если мониторинг интеграции отслеживает только первую, задержка на витрине может остаться незамеченной.

При продаже последней единицы товара риск особенно заметен. Учетная система фиксирует заказ и меняет доступный остаток, затем выгружает новое значение. Но если за это время витрина сохраняет прежнее количество, следующий заказ может попасть в систему уже после того, как товар закончился.

Принятый API-запрос подтверждает передачу данных площадке, но не гарантирует мгновенное изменение витрины.

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

Лимиты API Ozon: когда запросы начинают конкурировать за очередь

У Ozon есть конкретные ограничения на обновление остатков через Seller API. Методы допускают до 80 запросов в минуту; в одном запросе можно передать не более 100 пар «товар–склад». Одну и ту же пару запрещено обновлять чаще одного раза в 30 секунд.

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

Вторая распространенная причина ошибки возникает при массовой выгрузке товаров из 1С. Для запроса поиска по идентификаторам действует предел в 1000 значений product_id в одном filter.product_id. Превышение приводит к ошибке 400 invalid SearchRequest.Id. Внешне проблема может выглядеть как неудачная синхронизация остатков, хотя фактически сбой произошел раньше, на этапе формирования запроса.

Практический разбор стоит вести по логам интеграции. Для каждой пачки данных полезно сохранять:

• число пар «товар–склад» в запросе;
• время отправки и ответ API;
• идентификаторы товаров, по которым вернулась ошибка;
• количество повторных попыток и интервал между ними;
• состояние задания в очереди, если сервис использует отложенную отправку.

Если ошибка возникает только при массовых операциях, а одиночные обновления проходят, следует проверить размер пакета и частоту запросов. Увеличивать скорость отправки в такой ситуации бессмысленно: это может усилить конкуренцию за лимиты и увеличить задержку передачи данных по API.

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

Wildberries и Яндекс Маркет: запрос принят, витрина еще обновляется

Для Wildberries и Яндекс Маркета время отражения принятых через API данных об остатках на витрине может составлять до 15 минут. Поэтому ответ интеграции и видимое покупателю количество могут расходиться в пределах этого интервала.

Именно так часто проявляется вопрос «почему не обновляются остатки на Wildberries»: в учетной системе количество уже изменилось, API запрос принял, а карточка некоторое время показывает прежнее значение. Если ориентироваться только на экран личного кабинета, можно решить, что выгрузка не сработала, и отправить данные повторно. Но повторная отправка не ускоряет обработку витрины и может добавить лишние запросы.

При диагностике имеет смысл разделить состояния:

Это различие важно и при обновлении карточек или цен. Массовые изменения могут использовать отдельные методы и проходить свою обработку. Если цена изменилась, а остаток нет, не следует автоматически считать, что вся выгрузка зависла: разные типы данных могут иметь разные очереди, ограничения и ответы API.

Срок до 15 минут относится к отражению данных на витрине Wildberries и Яндекс Маркета после приема API-запроса. Для Ozon точный публичный SLA отображения остатков на витрине не зафиксирован в доступной документации, поэтому переносить на него эти сроки нельзя.

Новые карточки: отдельная очередь до загрузки остатка

На Wildberries создание карточки товара обрабатывается асинхронно. Первичная прогрузка может занимать до 30 минут; пока карточка находится в обработке, добавить к ней остатки на склады невозможно.

В интеграции это создает зависимость между двумя операциями. Сначала карточка должна получить состояние, при котором площадка разрешит управление остатками, затем можно отправлять складские данные. Если система запускает обе операции подряд без проверки готовности карточки, запрос на остатки может завершиться ошибкой или не дать ожидаемого результата.

Для новых товаров полезна отдельная логика обработки:

• после создания карточки получать ее статус, а не считать операцию завершенной по факту отправки запроса;
• сохранять задачу на установку остатка до подтверждения готовности карточки;
• повторять обновление после перехода карточки в подходящее состояние, соблюдая лимиты API;
• вести отдельный отчет по карточкам, которые долго не проходят первичную обработку.

Такой подход снимает ручную перепроверку каждой новой позиции. Он также помогает отличить ошибки создания карточки от задержки ее обработки. Для продавца это особенно актуально при массовом запуске ассортимента: один сбой в очередности операций способен оставить группу новых товаров без доступного остатка, даже если данные склада корректны.

Как сократить риск отмен при работе по FBS

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

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

Размер резерва зависит от оборачиваемости товара, количества площадок и того, как часто учетная система передает изменения. Универсальное значение здесь было бы фиктивной точностью: ассортимент с редкими продажами и товар, который разбирают одновременно на нескольких каналах, требуют разных настроек. Резерв следует рассчитывать по собственной динамике заказов и фактическим логам синхронизации.

Автоматизация складского учета маркетплейс должна закрывать не только передачу чисел, но и контроль результата. Полезные функции интеграции:

• пакетная отправка с учетом лимитов конкретного API;
• очередь заданий и ограниченные повторные попытки;
• раздельное состояние для создания карточки и обновления остатка;
• журнал запросов и ответов с привязкой к SKU и складу;
• уведомление о расхождении между учетным остатком и данными площадки;
• возможность задать долю выгружаемого остатка и страховой минимум.

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

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

Внедрение отдельного сервиса или доработка интеграции оправданы, когда ассортимент и поток заказов уже не позволяют вручную отслеживать очереди, ошибки и расхождения. Для небольшого каталога достаточно корректно настроенной выгрузки и страхового остатка. Для активного FBS-контур должен учитывать лимиты API, асинхронную обработку и состояние карточек, а его полезность измеряется не числом автоматизированных операций, а снижением ручных разборов и отмен из-за оверселлинга.