Обмен 1С и WooCommerce у большинства интернет-магазинов сводится к одному вопросу: товар, заведённый в 1С утром, должен появиться на сайте с правильной ценой и остатком, а вечерний заказ с сайта - лечь в 1С готовым документом без ручного переноса. Я настраивал такую связку и на типовом CommerceML-обмене, и через кастомные скрипты, когда стандартный формат не покрывал часть полей. В статье разбираю, как сопоставлять поля товаров и заказов между 1С и WooCommerce и где на практике чаще всего расходятся данные.
По теме статьи
Готовое решение
Ограничение доставки по зонам на карте в корзине Tilda
Виджет доставки в шапке сайта + ограничение оформления в корзине по зонам на Яндекс.Карте.
от9 000 ₽
Интернет-магазин
Интернет-магазин под ключ
Интернет-магазин под ключ — на Tilda, WordPress + WooCommerce, Next.js Commerce или кастомный бэкенд. Подберу платформу под бюджет, ассортимент и
от80 000 ₽
Как работает обмен 1С и WooCommerce между сайтом и учётной системой
Стандартный механизм обмена между 1С и сайтом на WooCommerce - протокол CommerceML 2.x, который часто называют просто «обмен по CommerceML» или «выгрузка 1С-сайт». 1С формирует XML-файлы: import.xml с описанием каталога (номенклатура, категории, характеристики, картинки) и offers.xml с ценами и остатками. На стороне WordPress эти файлы принимает плагин обмена через отдельный URL вида /?1c_exchange=… или через каталог загрузки в wp-content/uploads.
Обмен идёт в двух режимах. Полная выгрузка каталога происходит редко, раз в день или по ручному запуску, потому что это тяжёлая операция для сотен или тысяч товаров с картинками и характеристиками. Частичная выгрузка - только цены и остатки - обычно ставится по расписанию через регламентное задание в 1С, каждые 15-30 минут. На небольших магазинах я обычно ставлю 30 минут: этого достаточно, чтобы остатки не расходились критично, и сервер 1С не нагружается лишний раз.
Отдельно идёт обратный поток - заказы из WooCommerce в 1С. Тот же протокол передаёт документы заказов в формате XML, и 1С на своей стороне создаёт из них документы «Заказ покупателя» или «Реализация», в зависимости от настроенной схемы документооборота.
Сопоставление полей товаров: из 1С в WooCommerce
Поля 1С и WooCommerce называются по-разному и хранятся в разных структурах: часть данных WooCommerce держит в стандартных колонках wp_posts, часть в meta-полях, часть в таксономиях. Вот как я обычно сопоставляю основные поля номенклатуры:
| Поле в 1С | Поле в WooCommerce | Комментарий |
|---|---|---|
| Номенклатура (наименование) | Название товара (post_title) | - |
| Артикул | SKU (_sku) | Должен быть уникальным, иначе плагин обмена перезапишет не тот товар |
| Цена (тип «Розничная») | Обычная цена (_regular_price) | Цену со скидкой веду отдельным типом цены в 1С |
| Остаток по складу | Количество на складе (_stock) | При нескольких складах остатки суммируются или берётся один приоритетный склад |
| Группа номенклатуры | Категория товара (product_cat) | Вложенность групп 1С переносится в дерево категорий |
| Характеристика (цвет, размер) | Атрибут товара (pa_*) | Из характеристик 1С обычно строятся вариации WooCommerce |
| Штрихкод | Глобальный уникальный ID (global_unique_id) | Штатное поле ядра начиная с WooCommerce 9.2, в интерфейсе подписано «GTIN, UPC, EAN, or ISBN» |
| Картинка номенклатуры | Изображение товара / галерея | Первая картинка - главное изображение, остальные - в галерею |
Отдельно про штрихкод, потому что вокруг него до сих пор много путаницы. Заводить кастомное мета-поле не нужно: начиная с версии 9.2 в ядре WooCommerce есть штатное поле global_unique_id. В документации REST API оно описано как «GTIN, UPC, EAN or ISBN - a unique identifier for each distinct product and service that can be purchased», ведёт себя похоже на артикул и есть не только у товара, но и у вариации. По нему же можно искать: параметр search_fields в списке товаров принимает значения name, sku, global_unique_id, description и short_description. На практике это значит, что штрихкод из 1С кладётся в стандартное поле и остаётся вторым ключом сопоставления, если артикул в учётной системе и на сайте разошлись.
Что обычно ломается при сопоставлении характеристик
Характеристики 1С устроены иначе, чем атрибуты WooCommerce: в 1С это отдельный справочник, привязанный к номенклатуре, а в WooCommerce - атрибут товара, из которого строятся вариации (variable product). Если в 1С заведено «Цвет: Красный, Размер: M» одной характеристикой, а не двумя отдельными свойствами, при выгрузке WooCommerce получит один атрибут с составным значением вместо двух, и вариации собрать не получится. Это разбирают до настройки обмена, а не после - переделывать справочник характеристик на живом магазине с заказами гораздо дороже.
Сопоставление полей заказов: из WooCommerce в 1С
Обратный поток - из заказа WooCommerce в документ 1С - обычно вызывает больше вопросов, потому что тут добавляются поля оплаты и доставки, которых в стандартном CommerceML нет или они передаются нестандартно.
| Поле в WooCommerce | Поле в 1С | Комментарий |
|---|---|---|
| Номер заказа | Номер заказа покупателя | 1С добавляет свой префикс, чтобы не путать с внутренней нумерацией |
| Статус заказа (processing/completed/cancelled) | Статус документа (в работе/выполнен/отменён) | Соответствие статусов настраивается таблицей, а не жёстко в коде |
| Способ оплаты (эквайринг Т‑Банк, наличные) | Вид оплаты | Статус оплаты по вебхуку Т‑Банк - отдельный флаг, который часто забывают прокинуть |
| Способ доставки (СДЭК, самовывоз) | Способ доставки / склад отгрузки | Зона доставки СДЭК и стоимость передаются как доп. поля заказа |
| ФИО, телефон, email | Контактное лицо контрагента | - |
| ИНН, КПП (для юрлиц) | Контрагент (поиск/создание по ИНН) | Актуально для B2B-сегмента интернет-магазина |
| Состав заказа | Табличная часть документа | Каждая строка - товар, количество, цена на момент заказа |
Отдельно уточню про статус оплаты. Стандартный обмен CommerceML передаёт статус заказа, но не всегда - статус оплаты по эквайрингу. Если магазин принимает оплату через Т‑Банк, вебхук об успешной оплате меняет статус заказа в WooCommerce на «Выполняется», и уже этот статус синхронизируется в 1С как «Оплачен». Проблема возникает, если между сменой статуса и ближайшим сеансом обмена проходит время: 1С может ещё не знать об оплате, когда кладовщик уже собирает заказ по старым данным. Помогает не полагаться только на расписание, а запускать частичный обмен заказами сразу после вебхука оплаты - через доработку плагина обмена или отдельный сценарий на n8n, который слушает вебхук Т‑Банк и обновляет статус в 1С через HTTP-сервис. Такая доработка обычно стоит от 25 000 ₽, в зависимости от количества событий и полей, которые нужно обработать.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Остатки, цены и статусы: где чаще всего расходятся данные
На практике большинство обращений «обмен вроде работает, но что-то не так» сводятся к трём причинам.
Первая - гонка между обменом остатков и оформлением заказа. Если обмен идёт раз в 30 минут, а покупатель оформил заказ на последнюю единицу товара за минуту до синхронизации, следующий покупатель может заказать то же самое, чего уже физически нет. Резервировать остаток лучше в момент создания заказа в WooCommerce, а не в момент оплаты - тогда 1С получит актуальную картину быстрее.
Вторая - округление цены с НДС. Если в 1С цена хранится без НДС, а на сайте нужно показывать цену с НДС, округление на разных этапах (в 1С, в плагине обмена, в самом WooCommerce при отображении) может давать расхождение в рублях, которое потом всплывает при сверке с бухгалтерией.
Третья - несколько складов в 1С при одном остатке на сайте. Если товар физически лежит на двух складах, а WooCommerce показывает суммарный остаток, при отгрузке с одного склада возможна ситуация, когда на сайте остаток есть, а по факту он привязан к складу, с которого доставка в регион покупателя не осуществляется. Решение зависит от логики бизнеса: либо синхронизировать остаток только с одного приоритетного склада, либо выбирать склад в 1С по зоне доставки СДЭК уже на этапе создания заказа.
Типовой модуль обмена или кастомная интеграция под задачу
Готовые плагины обмена по CommerceML закрывают классический сценарий: каталог с ценами и остатками в одну сторону, заказы в другую. Если бизнес-процесс стандартный, я обычно не переизобретаю велосипед и настраиваю типовой обмен - это быстрее и дешевле. Кастомную интеграцию делаю, когда в процессе есть что-то, чего протокол не покрывает: свои статусы оплаты, привязка склада к зоне доставки СДЭК, синхронизация с внешней CRM параллельно с 1С, или заказ должен создавать сразу несколько документов в 1С.
| Критерий | Типовой обмен по CommerceML | Кастомная интеграция (REST API / n8n) |
|---|---|---|
| Что синхронизирует | Стандартный набор: каталог, цены, остатки, заказы | Только нужные поля, включая нестандартные |
| Скорость обновления данных | По расписанию, раз в 15-60 минут | В реальном времени, по вебхуку |
| Работа с нестандартными полями (статус оплаты, зона доставки) | Требует доработки плагина обмена | Изначально проектируется под задачу |
Когда типового обмена не хватает, я обычно закрываю разрыв не переписыванием всего механизма CommerceML, а отдельным скриптом или сценарием в n8n, который слушает нужные события и точечно обновляет конкретные поля через HTTP-сервис 1С или REST API WooCommerce. Это дешевле и надёжнее, чем чинить типовой плагин под задачу, для которой он не проектировался. Если нужно спроектировать такую связку с нуля, обычно начинаю с разработки кастомной интеграции между 1С и WooCommerce под конкретный процесс магазина, а не с попытки натянуть стандартный обмен на нестандартный сценарий.
Что делать, если обмен 1С и WooCommerce ломается после обновления
Обмен обычно падает в трёх ситуациях.
После обновления WooCommerce или темы - если плагин обмена зависит от конкретных хуков WooCommerce, а обновление меняет их поведение, товары перестают обновляться молча, без ошибки на экране. Проверяю логи обмена (у большинства плагинов есть отдельный лог сеансов) и сверяю дату последнего успешного сеанса с датой обновления плагинов.
После обновления конфигурации 1С - меняется версия схемы CommerceML или структура выгружаемых данных, и плагин на стороне WordPress не может её разобрать. Помогает временно откатить формат обмена на предыдущую версию CommerceML в настройках 1С, пока не доработан парсер на сайте.
При росте каталога - большой offers.xml или import.xml упирается в лимиты PHP (max_execution_time, memory_limit) или в лимит загрузки на хостинге, и обмен обрывается на середине, обновляя часть товаров. Решается увеличением лимитов на хостинге либо разбивкой выгрузки на пакеты по 100-200 товаров, что 1С умеет делать штатно.
Если обмен ломается регулярно и без явной причины, проще один раз завести журнал ошибок с оповещением - письмо или сообщение в Telegram при обрыве сеанса, чем каждый раз вручную проверять, дошли ли остатки до сайта.
Частые вопросы
Сколько времени занимает настройка обмена 1С и WooCommerce с нуля?
При типовом сценарии - каталог, цены, остатки, заказы без нестандартных полей - обычно укладываюсь в 3-5 рабочих дней, включая тестовый прогон обмена на реальных товарах и заказах. Если нужна кастомная логика (свои статусы, синхронизация склада по зоне доставки), срок растёт до 2-3 недель в зависимости от количества нестандартных сценариев.
Можно ли синхронизировать только заказы, без выгрузки каталога товаров?
Да, и на практике так делают нередко - например, когда каталог небольшой и его проще вести прямо в WooCommerce, а в 1С важно получать заказы для склада и бухгалтерии. В этом случае настраивают одностороннюю передачу документов заказа без обратной выгрузки номенклатуры, что упрощает обмен и снижает риск конфликтов данных по товарам.
Что делать, если в 1С несколько складов, а в WooCommerce нужен один остаток?
Есть два рабочих варианта. Первый - синхронизировать остаток только с одного приоритетного склада, с которого физически идёт отгрузка интернет-заказов. Второй - суммировать остатки всех складов в один показатель на сайте, а конкретный склад для отгрузки 1С определяет уже после получения заказа, по региону доставки. Второй вариант точнее, но требует доработки логики распределения заказов по складам в самой 1С.
Как передать статус оплаты Т‑Банк из WooCommerce в 1С автоматически?
Стандартный обмен CommerceML синхронизирует статус заказа по расписанию, а не мгновенно по факту оплаты. Чтобы 1С узнавала об оплате сразу, вебхук от Т‑Банк, который меняет статус заказа в WooCommerce на «Оплачен», дополнительно триггерит частичный обмен или отдельный запрос к HTTP-сервису 1С. Это закрывается небольшим скриптом или сценарием в n8n, который слушает событие оплаты и обновляет только один заказ, не дожидаясь общего сеанса обмена.