Интеграция WooCommerce с 1С и складом: ошибки

Интеграция WooCommerce с 1С и складом чаще всего ломается в трёх местах: заказ создаётся дважды, остаток на сайте не совпадает с реальным, а повторный обмен перезаписывает карточки товаров. Ниже — практический разбор для WordPress 6.x и WooCommerce 9.x: какие схемы обмена выбрать, где искать причину сбоя и какие проверки поставить до запуска.

Сначала определите, кто владеет данными

Главная ошибка — считать интеграцию одной кнопкой «обменяться». На самом деле у каждого объекта должен быть источник истины. Если товар создают и в WooCommerce, и в 1С, система не понимает, чьё название, цена или артикул правильные.

До настройки обмена составьте таблицу соответствий:

• 1С хранит номенклатуру, артикул, закупочную цену и остаток;
• WooCommerce хранит витринное описание, изображения, SEO-поля и статус публикации;
• складская система хранит фактическое наличие, резерв и отгрузку;
• заказ создаётся на сайте, а его подтверждение, резервирование и статус оплаты приходят из учётной системы;
• идентификатор связи должен быть постоянным: не название товара и не позиция в списке, а отдельный внешний ID.

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

Надёжный обмен начинается не с выбора плагина, а с ответа на вопрос: какая система имеет право изменить конкретное поле.

Три подхода к обмену

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

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

Ошибки, которые встречаются чаще всего

1. Сопоставление по названию товара

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

2. Остаток передают без резерва

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

3. Один заказ создаётся повторно

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

4. Статусы сопоставляют по одинаковым словам

Статус «в обработке» в WooCommerce может означать новый заказ, а в 1С — заказ, переданный на сборку. Нужна явная карта переходов: например, «оплачен на сайте» переводит заказ в состояние, где 1С может резервировать товар, а «отгружен» разрешает передать трек-номер обратно.

5. Изображения и характеристики передают без ограничений

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

6. Обмен проверяют только на боевом магазине

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

Как проверять интеграцию до запуска

1. Зафиксируйте карту данных. Для каждого поля укажите источник, формат, обязательность и направление обмена. Проверка: команда может ответить, какая система изменит цену, остаток и статус заказа.
2. Проверьте идентификаторы. Создайте товар с несколькими вариациями и выполните повторную выгрузку. Проверка: количество карточек не увеличилось, а изменения попали в существующие записи.
3. Прогоните повторную доставку. Отправьте один и тот же заказ дважды или имитируйте потерю ответа. Проверка: в WooCommerce и 1С осталась одна сущность заказа.
4. Проверьте остатки и резерв. Создайте параллельные заказы на один товар и измените остаток в учётной системе. Проверка: сайт показывает доступное, а не только физическое количество.
5. Отключите опасные автоматические действия. На тестовом контуре запретите массовое удаление товаров и автоматическую публикацию новых карточек. Проверка: ошибка импорта не приводит к исчезновению каталога.
6. Сохраните журнал. Записывайте внешний ID, время, направление, результат и текст ошибки. Проверка: по номеру заказа можно найти всю цепочку обмена без доступа к базе данных.

Когда очевидные решения не подходят

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

Прямое подключение к базе WooCommerce тоже кажется быстрым, но обход стандартного слоя приложения повышает риск повредить связи между заказами, товарами и метаданными. Для чтения отчётов такой доступ иногда оправдан, для записи заказов и остатков безопаснее использовать документированный механизм обмена и проверять его на версии WooCommerce 9.x.

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

Что ломается после запуска

• «Товар не найден». Проверьте внешний ID, тип товара и соответствие вариаций. Не создавайте новую карточку автоматически, пока не выяснили причину.
• «Дублируется заказ». Ищите повторную отправку после тайм-аута и отсутствие проверки уже принятого внешнего ID.
• «Остаток обновился с задержкой». Проверьте расписание очереди, фоновые задания WordPress, блокировки в 1С и время последнего успешного обмена.
• «Импорт остановился на середине». Смотрите лимиты времени выполнения, размер пакета, журнал PHP и ответ сервера. Повторный запуск должен продолжать обработку, а не создавать объекты заново.
• «Цена вернулась назад». Обычно два процесса считают себя владельцами поля. Оставьте один источник цены и запретите обратную перезапись.

Что измерять в проде

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

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