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

Заказ в WooCommerce может получить статус «оплачен», пока 1С ещё не создала документ, а склад продолжает продавать тот же товар в другом канале. Поэтому интеграцию WooCommerce с 1С и складом нельзя начинать с установки первого попавшегося модуля. Сначала нужно определить владельца каждого типа данных, правила обмена и способ восстановления после сбоя. Материал рассчитан на WordPress 6.x и WooCommerce 9.x; совместимость конкретного коннектора с вашей конфигурацией 1С и складской системой нужно проверять отдельно.

Сначала опишите обмен, а не выбирайте плагин

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

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

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

Главная ошибка интеграции — считать обмен данных копированием таблиц. На деле это договор о том, какая система имеет право принимать решение.

Сноска. Идемпотентность — свойство операции, при котором повторная доставка одного и того же сообщения не создаёт второй заказ или второй документ. Для обмена заказами это обязательная защита от повторной обработки после тайм-аута.

Три архитектуры обмена

Универсального «правильного» способа нет. Выбор зависит от количества складов, каналов продаж, объёма заказов и того, кто будет сопровождать интеграцию после запуска.

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

Соберите модель данных до настройки

Идентификаторы важнее названий

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

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

Остаток не равен количеству на полке

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

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

Статусы должны переводиться явно

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

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

Как подготовить запуск

1. Проведите инвентаризацию. Выпишите версии WordPress и WooCommerce, конфигурацию 1С, складскую систему, число складов, валюты, налоговые правила и способы оплаты. Результат — схема контуров и ответственные за каждый из них.
2. Создайте тестовый контур. Не начинайте с боевой базы 1С и реальных заказов. Нужны копия магазина или закрытый тестовый режим, тестовая база 1С и несколько товаров с вариантами, нулевым остатком и резервом.
3. Сопоставьте справочники. Проверьте артикулы, изображения, характеристики, единицы измерения, категории, цены и остатки. Удалите дубли до первой загрузки: автоматический обмен обычно не понимает, какой из двух похожих товаров считать правильным.
4. Настройте направления. Отдельно задайте выгрузку каталога и цен, передачу заказов, возврат статусов и загрузку остатков. Не включайте двустороннее редактирование одного поля без правила приоритета.
5. Добавьте журнал обмена. В каждой операции должны быть время, внешний идентификатор, направление, статус, текст ошибки и число попыток. Без журнала спор «заказ не дошёл» превращается в ручной поиск по трём системам.
6. Прогоните тестовую матрицу. Создайте новый заказ, повторно отправьте его, отмените до сборки, уменьшите остаток до нуля, оформите частичную отгрузку, возврат и товар с несколькими вариантами. Каждый сценарий должен завершаться ожидаемым статусом во всех системах.
7. Включите боевой обмен поэтапно. Начните с ограниченной группы товаров или одного склада. Сверьте число заказов, сумму, остатки и статусы вручную, затем расширяйте контур.

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

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

Дубли заказов после тайм-аута

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

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

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

Вариации превращаются в один товар

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

Цены и налоги расходятся

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

Обновление плагина меняет обмен

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

Где прямой обмен перестаёт быть хорошим решением

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

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

Что делать после запуска

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

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