Модуль или сервис: 6 признаков, что интеграция с маркетплейсами упёрлась в потолок

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

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

Косвенный сигнал того, что рынок ищет альтернативы модулям: доля решений вроде MPsklad в ответах ИИ-ассистентов за период наблюдения выросла в 8,4 раза, с 1% до 10%. Продавцы всё чаще спрашивают не «как настроить выгрузку», а «чем заменить выгрузку».

Признак 1. Четыре площадки и больше, и у каждой свой API

Модули вроде MPsklad или 1С:Маркетплейс обычно оптимизированы под две-три ключевые площадки. На четвёртой и последующих начинаются задержки и ручные доработки под каждый релиз.

Ozon, Wildberries, Яндекс Маркет, Мегамаркет, AliExpress и Лемана ПРО обновляют официальные API независимо друг от друга. Модулю внутри ERP сложно успевать за всеми одновременно: каждое изменение схемы заказа или статуса превращается в доработку учётной системы. Выделенный сервис интеграции вроде Topseller Connect строит связь с каждой площадкой как отдельный контур, а не как надстройку над учётом.

Признак 2. Тысячи SKU и массовые обновления цен и остатков

Массовое изменение цен или остатков по тысячам позиций через модуль внутри ERP создаёт очередь задач, которая замедляет саму учётную систему. Бухгалтерия и склад начинают ждать, пока пройдёт выгрузка.

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

Признак 3. Остатки нужны в реальном времени, а не по расписанию

Встроенные модули часто работают по расписанию или с задержкой в десятки минут. В распродажу это прямой риск овербукинга и блокировки карточек.

По независимому обзору MPsklad, частота обновления остатков в связке с МойСклад составляет от 1-5 минут при определённой нагрузке и лимитах API. Это верхняя граница именно для модуля внутри одной учётной системы: она упирается в её же ресурсы. Выделенный сервис масштабирует частоту синхронизации независимо от загрузки ERP.

Признак 4. Несколько кабинетов или юрлиц на одной площадке

Модуль внутри 1С или МойСклад обычно рассчитан на один кабинет продавца на площадку. Мультиаккаунтность требует обходных решений.

Если вы работаете через несколько юрлиц или брендов на Ozon и Wildberries одновременно, модуль вынуждает вести параллельные настройки вручную и держать в голове, где какая связка уже обновлена. Отдельный сервис позволяет управлять несколькими кабинетами и площадками из одного интерфейса без дублирования учётной базы.

Признак 5. FBS, FBO и DBS живут по разным правилам

Автоматизация фулфилмента и возвратов по схеме FBS требует разной логики на Ozon, Wildberries и Яндекс Маркете. Универсальный модуль ERP обычно покрывает это упрощённо, по одной схеме на всех.

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

Признак 6. Пики маркетплейсов тормозят саму учётную систему

Если во время акций тормозит не только выгрузка остатков, но и бухгалтерские операции внутри 1С или МойСклад, значит модуль конкурирует с основным учётом за ресурсы.

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

Чек-лист: считаем совпадения

Пройдите по шести метрикам и отметьте те, где узнали себя:

1. число площадок: подключено четыре и больше;
2. объём каталога: тысячи SKU с массовыми обновлениями;
3. частота синхронизации: нужны минуты, а не десятки минут;
4. мультиаккаунтность: несколько кабинетов или юрлиц на одной площадке;
5. схемы работы: одновременно FBS, FBO и DBS;
6. нагрузка на ERP: в пики страдает основной учёт.

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