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

Связка WooCommerce с 1С и складом обычно запускается за несколько часов, но уже на следующий день показывает реальные проблемы: товар продан в двух каналах, заказ задублировался, а остаток на сайте не совпал с ячейкой склада. Для WooCommerce 9.x, WordPress 6.x и типовых конфигураций 1С вроде «Управление торговлей» 11.x безопаснее начинать не с выбора плагина, а с правил обмена: кто владеет ценой, остатком, статусом заказа и карточкой товара.

Сначала определите владельца каждого поля

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

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

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

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

Три схемы интеграции и их цена

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

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

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

Как организовать обмен без дублей

1. Зафиксируйте идентификаторы

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

Если модуль создаёт новый товар при отсутствии совпадения, включите отдельный отчёт о таких случаях. Автоматическое создание карточек без контроля быстро порождает пары вроде «Футболка чёрная» и «Футболка черная».

2. Разделите первичную загрузку и регулярный обмен

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

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

3. Обрабатывайте повтор безопасно

Идемпотентность^[1] означает, что повторная доставка одного и того же события не создаёт второй заказ или вторую отгрузку. Для заказа нужен внешний номер из WooCommerce, а для каждой операции — уникальный идентификатор события или документа.

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

4. Не путайте остаток и доступность

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

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

Заказ: самый дорогой участок обмена

Каталог можно перепроверить глазами. Ошибка в заказе напрямую затрагивает деньги, доставку и клиента. Поэтому статусы нельзя связывать простым правилом «processing в WooCommerce равен проведённому заказу в 1С».

Составьте карту переходов:

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

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

Что чаще всего ломается

Разные справочники и вариации

В WooCommerce вариация — отдельный объект со своими атрибутами и остатком. В 1С она может быть характеристикой номенклатуры, а в складской системе — самостоятельным SKU. Если коннектор связывает только родительский товар, остатки цветов и размеров смешиваются.

Валюта, налоги и округление

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

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

Тайм-ауты и частичные сбои

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

Кэш и фоновые задачи WordPress

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

Когда выбирать каждый подход

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

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

Что проверить перед запуском

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

Что делать дальше

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

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

[1] Идемпотентность — свойство операции, при котором повторное выполнение с теми же данными сохраняет тот же результат и не создаёт дубликат.