Интеграция WordPress и WooCommerce с 1С: товары, остатки и заказы

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

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

Какие данные обычно синхронизируют между 1С и WooCommerce

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

• товары и группы каталога;
• артикулы и внутренние идентификаторы;
• характеристики и вариации;
• цены и разные типы цен;
• остатки по складам или агрегированный остаток;
• изображения и свойства товаров;
• заказы WooCommerce;
• состав заказа, покупатель, доставка и оплата;
• статусы заказа, если нужен обратный обмен.

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

CommerceML — стандартный путь обмена с 1С

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

На стороне WordPress/WooCommerce для такого подхода нужен обработчик, который понимает протокол 1С, принимает файлы CommerceML, разбирает каталог и корректно сопоставляет его с сущностями WooCommerce.

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

Второй подход — API и отдельный интеграционный слой

Не каждый проект удобно строить вокруг полного CommerceML-обмена. Иногда 1С уже отдаёт данные через HTTP-сервис, отдельный middleware или корпоративный API. Тогда WooCommerce можно связать через REST API, собственные WordPress endpoints и webhooks.

Официальная документация WooCommerce предоставляет REST API для работы с товарами и заказами. Webhooks позволяют реагировать на события вроде создания или изменения заказа и отправлять данные во внешний обработчик.

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

Что выбрать: CommerceML или API

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

Источник истины: главное решение до написания кода

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

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

Это пример архитектурного решения, а не универсальная схема: реальные правила утверждаются по вашему процессу.

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

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

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

Вариации и характеристики

Одна из самых трудных частей обмена — товары с характеристиками: размер, цвет, объём, комплектация или другие варианты. В WooCommerce это обычно variable product и отдельные variations. В 1С структура может отличаться в зависимости от конфигурации.

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

Неправильная логика здесь приводит к одинаковым вариациям, потерянным SKU или остаткам, записанным не в тот вариант.

Цены и несколько типов цен

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

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

Остатки и частота синхронизации

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

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

Передача заказов из WooCommerce в 1С

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

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

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

Почему интеграция должна переживать временный сбой 1С

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

Повтор должен быть идемпотентным: один заказ WooCommerce не должен превращаться в несколько одинаковых документов 1С. Для этого используется стабильная связь ID WooCommerce ↔ ID 1С и проверка результата предыдущих попыток.

Подобный подход я использую и в других интеграциях. Подробнее про retries, webhooks и idempotency есть в статье об интеграции WordPress с CRM через REST API.

Логи без секретов и персональных данных

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

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

Где размещать код интеграции в WordPress

Критичный обмен с учётной системой не стоит прятать в functions.php темы. Дизайн сайта может поменяться, а интеграция должна продолжать работать независимо.

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

Что нужно для оценки интеграции WordPress с 1С

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

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

После этого можно выбрать CommerceML, REST API или смешанный вариант и оценить реальный объём разработки. Для комплексной работы с магазином есть направление WooCommerce-разработки.

Как проходит разработка

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

Если нужно связать существующий WordPress/WooCommerce-магазин с 1С, можно прислать описание текущей схемы A.S Groups. Я сначала разберу точки обмена и риски, а затем предложу вариант интеграции без обязательной переделки магазина с нуля.

Официальные источники

• 1С — обмен данными с интернет-магазином
• 1С — протокол обмена с сайтом
• 1С — CommerceML 2
• WooCommerce Developer Docs — REST API