Когда обмен 1С с Wildberries начинает ломаться

Не «настройка интеграции», а поиск причины сбоя и стабилизация. Чтобы заказы не дублировались, остатки не расходились, а обмен не падал ночью

Адаптирую под ваш контур Прямая работа с API Для нетиповых баз

Диагностика без обязательств. Отвечаю лично.

Работаю с УТ, КА, УНФ и нетиповыми конфигурациями 1С

Специфика обмена с Wildberries: polling, высокая нагрузка и рассинхроны

WB — единственный маркетплейс, где обмен идёт через polling (опрос по расписанию), а не через события или webhook. Это создаёт уникальные риски: рассинхроны остатков при частичных отгрузках, дубли при повторной обработке и критический SLA на FBS-сборку.

Polling-модель

Обмен идёт по расписанию, а не по событиям. При 500+ заказов/день polling не справляется: таймауты, потеря пакетов, пропуск циклов. Решение: переход на событийную модель или гибридный подход.

Рассинхроны остатков

Самая частая проблема WB. При частичной отгрузке остатки в 1С и на WB расходятся. Накопленный дрейф: 20–30% расхождение за месяц. Решение: мониторинг остатков в реальном времени, аудит регистров.

Дубли заказов

При таймауте 1С очередь WB отправляет повтор. Модуль не проверяет external_id — создаёт дубль. Решение: upsert вместо insert, проверка идемпотентности.

Критический SLA FBS

WB штрафует за срыв сроков FBS-отгрузки: до 35 000 ₽/день. Сборочные задания зависают, склад простаивает. Решение: мониторинг SLA, автоматический перезапуск зависших заданий.

Где именно рвётся обмен с Wildberries

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

Wildberries
портал
API WB
❌ таймаут 504
❌ 429 rate limit
❌ токен истёк
Очередь обмена
❌ дубли обработки
❌ потеря пакетов

обработчик

регистры
Склад
❌ конфликт регистров
❌ двойное списание
Остатки WB
❌ рассинхрон
Стабильно
✔ заказы идут
Точка сбоя — здесь рвётся
После исправления
Рабочий узел

Диагностика начинается не с «настройки», а с определения — в каком именно звене цепочки происходит разрыв. Ниже — разбор каждого узла.

Что именно ломается в обмене с Wildberries

Типичные точки отказа. Каждая из них — не «глюк модуля», а конкретная инженерная причина

Дубли заказов

API WB передаёт заказ, модуль создаёт документ. При повторной обработке — второй такой же. Причина: нет проверки идемпотентности по external_id.

Инженерное решение: проверка external_id перед созданием, upsert вместо insert

Расхождение остатков

В 1С остаток 50, на WB — 20. После частичной отгрузки цифры расходятся. Причина: обмен берёт остатки не из того регистра.

Инженерное решение: аудит регистров учёта, унификация источника данных

Задержка статусов заказов

Статус «Доставлен» приходит через 3 дня. Клиент звонит, менеджеры не знают, где заказ. Причина: регламентное задание раз в сутки вместо событийной модели.

Инженерное решение: переход на событийные уведомления в реальном времени

Обрыв соединения с API

Обмен работал и перестал. Без видимой причины. Причина: истёк токен, изменился API-ключ, или WB обновил формат ответа.

Инженерное решение: логирование кодов ответа, мониторинг срока токенов

Обмен тормозит на больших объёмах

На 100 заказах работало, на 1000 — таймауты и потери. Причина: запросы идут последовательно, без пакетной обработки.

Инженерное решение: пакетная отправка, асинхронная обработка, контроль очередей

Хаос после обновления 1С

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

Инженерное решение: адаптация кода под новую структуру, документирование зависимостей

Почему типовой модуль интеграции с WB ломается

Инженерный разбор: четыре архитектурные проблемы, которые проявляются при росте бизнеса

Polling без идемпотентности

Обмен идёт по расписанию, а не по событиям. При таймауте 1С очередь WB отправляет повтор. Модуль не проверяет external_id — создаёт дубль. На 500+ заказов/день это даёт 20–40 дублей в сутки. Коммерсант тратит 2–3 часа на ручную чистку.

Нет мониторинга регистров

Модуль не отслеживает, из какого регистра берутся остатки. После обновления конфигурации или доработки регистр может измениться — модуль продолжает писать в старый. Расхождение нарастает: 5–7% в день, к концу месяца до 30%.

Закрытый код обработчика

Нельзя посмотреть, как модуль обрабатывает API-запрос или формирует ответ. При сбое — только «обратиться в поддержку». Нет возможности оперативно исправить ошибку или адаптировать под изменения API WB.

Нет управления очередью

Все запросы идут последовательно в одном потоке. При 1000+ заказов очередь растёт, таймауты множатся, обмен встаёт колом. Нет приоритизации: сборочный заказ на FBS может ждать обработки 40 минут — WB штрафует до 35 000 ₽/день.

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

Как проходит стабилизация обмена с WB

Инженерный процесс: от аудита polling-модели до мониторинга SLA FBS

1
Аудит polling-модели. Смотрю тайминги очереди обмена, частоту опроса API WB, логи таймаутов и повторных запросов. Определяю, на каких объёмах начинаются сбои и где узкое место.
2
Внедрение upsert и external_id. Добавляю проверку идемпотентности: перед созданием заказа проверяю external_id. Если заказ уже существует — обновляю данные, а не создаю дубль. Настраиваю логирование для мониторинга.
3
Унификация регистров учёта. Аудирую, из каких регистров модуль берёт остатки и куда пишет склад. Привожу к единому источнику данных. Добавляю сверку после каждого цикла обмена.
4
Мониторинг SLA FBS. Настраиваю контроль времени сборки: если сборочное задание зависает дольше порога — автоматический перезапуск и уведомление. Предотвращаю штрафы WB за срыв отгрузки.

Разбор реальных сбоев с Wildberries

Не «что я сделал», а что оказалось причиной — и как было исправлено

1С:УТ + Wildberries

Заказы дублировались при каждом обмене

Симптом

Менеджеры видели одни и те же заказы по 2–3 раза. Тратили часы на сверку и удаление дублей.

Что оказалось причиной

Очередь обмена WB при таймауте 1С отправляла повторные запросы. Модуль не проверял, существует ли уже заказ с таким ID — создавал новый. За 2 месяца накопилось 340+ дублей. Подробнее о дублях заказов →

Как исправлено

Добавлен поиск по external_id перед созданием. Если заказ уже есть — обновляются данные, а не создаётся дубль. Плюс настроено логирование для мониторинга.

0 дублей · −12 часов ручной сверки в неделю
🔍 Артефакт диагностики — очередь обмена WB
[02:14:33.221] API WB: order #WB-889102 status=new
[02:14:33.225] 1C: Заказ создан #О00-33112 ✓
[02:14:38.112] Очередь: order #WB-889102 status=new [ПОВТОР]
[02:14:38.115] 1C: Заказ О00-33114 создан — ДУБЛЬ! (external_id не проверен)
→ Повторная обработка без идемпотентности. Нет проверки external_id перед созданием.
1С:КА + Wildberries

Остатки на WB расходились с 1С каждый вечер

Симптом

Утром остатки сходятся, к вечеру — расходятся. Товар продаётся на WB, а в 1С резерв не снимается.

Что оказалось причиной

Обмен брал остатки из регистра «Свободные остатки», а склад списывал товар через «Товары на складах». После каждой отгрузки два регистра расходились, и обмен отправлял на WB завышенные остатки. Подробнее о расхождении остатков →

Как исправлено

Унифицирован источник данных — обмен теперь берёт остатки из того же регистра, куда пишет склад. Добавлена сверка после каждого цикла обмена.

Расхождение 0 · −100% отмен из-за отсутствия товара
🔍 Артефакт диагностики — конфликт регистров учёта
[08:00:03] Обмен WB: остатки из регистра «Свободные остатки»
[08:00:03] Арт. 4455 — 28 шт. → WB API: stocks/28 ✓
[15:42:00] Склад: реализация РТ-1124, арт. 4455, −6 шт.
[15:42:00] Регистр «Свободные остатки»: всё ещё 28 шт. (склад пишет в «Товары на складах»)
[16:00:03] Обмен WB: 28 шт. → WB показывает 28 вместо 22
→ Каждая отгрузка увеличивает расхождение. К вечеру разрыв составил 18 единиц.
АС

Александр

Специализируюсь по интеграции 1С и внешних систем

5+ лет восстанавливаю обмены 1С с маркетплейсами. Десятки стабилизированных интеграций с Wildberries, Ozon, Яндекс Маркетом и Lamoda. Работаю с УТ, КА, УНФ, ERP и нетиповыми конфигурациями.

40+ восстановленных обменов WB, Ozon, YM, Lamoda Опубликовано: 15.06.2026 · Обновлено: 28.06.2026

Кому нужна стабилизация обмена с WB

Типовые ситуации, когда обмен с Wildberries требует инженерного вмешательства

Обмен то работает, то нет

Заказы загружаются хаотично: то все, то половина, то ни одного. Менеджеры не знают, можно ли доверять данным в 1С.

Каждый день новые дубли заказов

Утром удалили 15 дублей, к вечеру — ещё 10. Клиентам уходят повторные уведомления, менеджеры тратят часы на сверку.

Остатки разъезжаются каждую неделю

Товар продаётся, а в 1С резерв не снимается. Несколько раз в неделю — отмена заказов из-за отсутствия товара на складе.

Объёмы выросли — обмен встал

Было 50 заказов в день — работало. Стало 500+ — постоянные таймауты 504, потеря пакетов, обмен зависает на ночь.

Частые вопросы о стабилизации обмена с WB

Почему обмен 1С с Wildberries создаёт дубли заказов?

Из-за polling-модели: очередь обмена WB при таймауте 1С отправляет повторные запросы. Типовой модуль не проверяет external_id — создаёт новый документ вместо обновления существующего. Решение: внедрение проверки идемпотентности и upsert-логики. За 2 месяца без этой проверки накапливается 340+ дублей.

Почему расходятся остатки между 1С и Wildberries?

Самая частая причина — обмен берёт остатки из регистра «Свободные остатки», а склад списывает товар через «Товары на складах». После каждой частичной отгрузки регистры расходятся, и на WB отправляются завышенные остатки. Решение: унификация источника данных и сверка после каждого цикла обмена.

Сколько стоит стабилизация обмена 1С с WB?

Фиксированная смета после диагностики. Стоимость зависит от сложности: количество точек сбоя, объём данных и конфигурация 1С. Диагностика — бесплатно и без обязательств. Критические сбои устраняю в день обращения.

Чем ваша стабилизация отличается от типового модуля?

Типовой модуль — закрытый код с жёсткой привязкой к стандартной конфигурации 1С. Моя стабилизация — открытая API-интеграция: открытый код, обработка ошибок, мониторинг регистров, управление очередью, масштабирование под реальные объёмы без замены рабочей системы.

Как быстро вы можете исправить обмен с WB?

Диагностика занимает 1–2 дня. Критические сбои (обмен полностью не работает) — в день обращения. Полная стабилизация с мониторингом — от 3 до 10 дней в зависимости от сложности конфигурации. После завершения даю документацию и гарантию стабильности.

Вы работаете с нетиповыми конфигурациями 1С?

Да. Специализируюсь на нестандартных базах: доработанные УТ, КА, УНФ, ERP и самописные конфигурации. Если модуль не видит нужные регистры или падает на нестандартных документах — это моя основная задача. В сложных случаях приезжаю лично для аудита.

Диагностика без обязательств

Проверю, почему ломается обмен с Wildberries

Опишите симптомы — найду причину и покажу решение

Дубли заказов Остатки не сходятся Обмен зависает Ошибки API WB После обновления 1С

Можно без деталей — разберусь сам

Отвечаю лично
Без спама и передачи контактов
Нет обязательств после диагностики

Отвечу в течение дня с планом диагностики