Другие товароучётные системы и WooCommerce

МойСклад и 1С — не единственные варианты внешнего учёта. Если бизнес уже работает в Saby (бывшая «СБИС»), в отраслевой ERP или в самописной системе, вопрос не в том, «какая система популярнее», а в том, существует ли рабочий способ обмена с WooCommerce.

Наличие интеграции ≠ возможности интеграции

Сам факт упоминания системы в описании плагина ничего не говорит о том, что он умеет. Например, ITGALAXY указывает поддержку СБИС в описании своего продукта — но это лишь точка входа для проверки.

Уточнять нужно четыре вещи:

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

Ответ «есть интеграция» без этих четырёх пунктов — это не ответ.

Сценарии, с которыми сталкиваются чаще всего

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

Saby/СБИС как учётная система. Проверяются те же пункты, что и для 1С: конфигурация, состав выгрузки, склады, цены, возвраты. Отличие в том, что экосистема плагинов меньше, поэтому вероятность самописного обмена выше.

Промежуточный слой. Иногда между сайтом и учётной системой ставят интеграционную платформу (Make, n8n, собственный сервис). Это оправдано, если систем больше двух, но добавляет ещё одну точку отказа и задержку — её нужно учитывать в буфере доступности.

Что важно в самописном обмене

Если готового решения нет, минимальный контракт выглядит так:

Идентификаторы. Каждый товар и заказ имеет внешний ID; сопоставление по названию запрещено.
Идемпотентность. Повторная обработка события не создаёт дубликатов и не списывает остаток дважды.
Ошибка ≠ ноль. При недоступном API остатки сохраняют последнее известное значение, а не обнуляются.
Журнал. Каждая операция обмена логируется: что отправлено, что получено, что упало.
Ручной запуск. Есть возможность перезапустить обмен за период после сбоя.
Мониторинг. Видно время последнего успешного обновления; при простое дольше порога — уведомление ответственному.

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

Когда менять систему, а не интеграцию

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

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

Это решение уровня бизнеса, а не разработки: считается стоимость владения, а не только цена лицензий.

Связанные страницы

Остатки в WooCommerce: где вести учёт — выбор схемы и общие проверки.
1С — как оценивать обмен по конфигурациям и составу данных.
Битрикс24 — вариант, когда учёт переносят в CRM.
Каналы продаж и WMS — если к учёту добавляются розница, маркетплейсы и склад.