За те годы, что я веду проекты на стыке 1С и сайтов, обмен данными между учётной системой и витриной настраивал десятки раз, и почти везде в основе лежит commerceml формат обмена. Это открытый XML-протокол для передачи каталога, цен, остатков и заказов между 1С и сайтом, и разбираться в его устройстве полезно, даже если основную работу берёт на себя плагин или встроенный модуль CMS. Без понимания структуры файлов первая же ошибка синхронизации превращается в разгадывание чёрного ящика. Ниже разберу, как устроена сессия обмена, какие файлы в ней участвуют и на что смотреть, когда синхронизация встаёт колом.
Что такое CommerceML и откуда он взялся
CommerceML появился как формат обмена между 1С и Битрикс, потом стал фактическим стандартом для любых CMS и интернет-магазинов. В основе лежит набор XML-схем: классификатор товаров, каталог, предложения с ценами и остатками, заказы. Опубликованных стандартов у 1С три: первая редакция CommerceML, вторая редакция и отдельный стандарт CommerceML EDI. На живых проектах речь почти всегда про вторую редакцию, её актуальная XML-схема это 2.10, а номер схемы стоит в атрибуте ВерсияСхемы самого файла обмена. Версии 3.0 среди опубликованных стандартов нет.
Сам обмен всегда идёт в двух направлениях с разным содержимым. Из 1С на сайт уходит каталог: товары, категории, цены, остатки. С сайта в 1С возвращаются заказы: что купили, кто покупатель, какая доставка и оплата. 1С выступает источником истины по товарам, сайт по заказам, и CommerceML синхронизирует оба потока без ручного экспорта и импорта.
Протокол обмена: как проходит сессия между 1С и сайтом
Технически commerceml формат обмена работает поверх обычного HTTP. Обработчик обмена публикуется на сайте по отдельному адресу, а 1С обращается к этому адресу как HTTP-клиент, передавая параметры type и mode. Опишу последовательность запросов, как она проходит на практике при выгрузке каталога.
# 1. Проверка логина и пароля, сайт возвращает идентификатор сессии
curl -u "exchange_user:exchange_pass" \
"https://shop.example.ru/exchange1c/?type=catalog&mode=checkauth"
# ответ: success + имя и значение сессионной куки
# 2. Параметры приёма: поддержка zip и лимит размера файла за запрос
curl "https://shop.example.ru/exchange1c/?type=catalog&mode=init&PHPSESSID=abc123"
# ответ: zip=no, file_limit=52428800
# 3. Заливка файла каталога
curl -X POST --data-binary @import.xml \
"https://shop.example.ru/exchange1c/?type=catalog&mode=file&filename=import.xml&PHPSESSID=abc123"
# 4. Запуск импорта на стороне сайта
curl "https://shop.example.ru/exchange1c/?type=catalog&mode=import&filename=import.xml&PHPSESSID=abc123"Checkauth: 1С логинится, сайт возвращает идентификатор сессии, обычно имя и значение сессионной куки, потому что 1С не всегда умеет штатно работать с cookies и передаёт их вручную в каждом следующем запросе.
Init: сайт сообщает параметры приёма, поддерживается ли приём zip-архивом и какой максимальный размер файла разрешён за один запрос. У крупных каталогов на 10-20 тысяч товаров эта цифра критична: если 1С шлёт файл больше лимита, обмен рвётся посередине без внятной ошибки.
File: 1С заливает XML-файлы кусками, сайт складывает их во временную папку.
Import: после того как все файлы получены, сайт запускает разбор и импорт в базу магазина.
Для заказов схема зеркальная. 1С запрашивает у сайта mode=query, что нового появилось с прошлого обмена, получает orders.xml прямо в теле ответа, обрабатывает заказы у себя и подтверждает приём через mode=success, чтобы сайт пометил эти заказы как выгруженные и не слал их повторно.
Файлы обмена: import.xml, offers.xml и заказы
Import.xml самый тяжёлый файл: в нём классификатор, дерево категорий и характеристик, и карточки товаров с артикулами, названиями, описаниями, картинками и привязкой к группам. Для каталога на несколько тысяч позиций такой файл может весить десятки мегабайт, поэтому 1С умеет резать его на несколько частей и заливать их отдельными файловыми запросами.
Offers.xml отвечает за цены и остатки и обычно самый частый файл в расписании обмена: структура каталога и характеристики меняются редко, а цены и остатки актуализируются хоть каждый час. Вот как выглядит фрагмент такого файла на практике.
<?xml version="1.0" encoding="UTF-8"?>
<КоммерческаяИнформация ВерсияСхемы="2.05" ДатаФормирования="2026-09-01T10:00:00">
<ПакетПредложений>
<Ид>web-shop-01</Ид>
<ИдКаталога>catalog-01</ИдКаталога>
<Предложения>
<Предложение>
<Ид>00001</Ид>
<Наименование>Кроссовки летние, синие, 42</Наименование>
<Цены>
<Цена>
<ИдТипаЦены>b7c5c6f0-price</ИдТипаЦены>
<ЦенаЗаЕдиницу>4990</ЦенаЗаЕдиницу>
<Валюта>RUB</Валюта>
</Цена>
</Цены>
<Количество>7</Количество>
</Предложение>
</Предложения>
</ПакетПредложений>
</КоммерческаяИнформация>Товары и предложения связаны по идентификатору, который 1С генерирует один раз и не меняет, поэтому переименование товара в 1С не рвёт связь с карточкой на сайте. А вот смена идентификатора, например при пересоздании номенклатуры, означает, что сайт создаст новую карточку вместо обновления старой. На моей практике это самая частая причина задвоенных товаров после миграции 1С.
| Файл | Направление | Содержимое | Типичная частота |
|---|---|---|---|
| import.xml | 1С в сторону сайта | категории, характеристики, карточки товаров | при изменении каталога, обычно раз в сутки |
| offers.xml | 1С в сторону сайта | цены и остатки по предложениям | несколько раз в день, иногда раз в час |
| orders (обмен заказами) | сайт в сторону 1С | новые заказы, статусы, реквизиты доставки и оплаты | каждые 10-15 минут |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Обмен CommerceML в WooCommerce
В WooCommerce обмен обычно заводится через отдельный плагин, который поднимает у себя обработчик под протокол CommerceML и генерирует пару логин-пароль для 1С. Настройка с моей стороны выглядит так.
- Ставлю плагин обмена, получаю адрес обработчика и создаю технического пользователя с доступом только к этому разделу.
- В 1С в настройках публикации обмена с сайтом указываю адрес, логин, пароль и каталог для временных файлов.
- Запускаю тестовый обмен на небольшом срезе каталога, десяток товаров, проверяю, что категории и цены легли туда, куда нужно, и только потом ставлю полный каталог в расписание.
- Отдельно проверяю обмен заказами: оформляю тестовый заказ на сайте и смотрю, что он забрался в 1С со всеми реквизитами доставки и оплаты.
На паре проектов с приёмом платежей через T‑Bank для WooCommerce обмен CommerceML настраивал независимо от эквайринга. Это два разных модуля, они не пересекаются по коду, просто оба должны корректно писать статус заказа, чтобы 1С видела оплаченные заказы отдельно от неоплаченных.
CommerceML в Tilda и других конструкторах
В Tilda обмен с 1С через CommerceML встроен в интерфейс, но настраивается в обратную сторону, чем обычно ждут: адрес и доступы выдаёт сама Тильда, а вписывают их в 1С. Порядок такой: раздел «Товары» на Тильде (он доступен после подключения модуля «Каталог товаров»), кнопка «Синхронизация через CommerceML», оттуда копируются значения полей «Ссылка на коннектор», «Имя пользователя», «Пароль», и уже они вставляются в 1С в поля «Адрес сайта», «Имя пользователя», «Пароль». Обмен запускает 1С кнопкой «Выполнить обмен»: товары уезжают на Тильду, заказы уходят в 1С. Для интернет-магазина на несколько сотен позиций с простой структурой характеристик этого достаточно.
Ограничение обычно упирается не в сам протокол, а в структуру каталога Tilda: если у товара много вложенных характеристик, комплектов или разных единиц измерения, штатный маппинг полей может не покрыть всё, что 1С присылает в import.xml. В таких случаях помогает кастомную доработку под Tilda, которая донастраивает обработку конкретных полей поверх штатного обмена, а не заменяет его.
Частые ошибки обмена 1С и сайта
- Кодировка файлов: 1С по умолчанию отдаёт Windows-1251, часть современных CMS ждут UTF‑8, и если конвертацию не настроить на стороне обработчика, вместо каталога сайт получит битые символы вместо кириллицы.
- Превышение лимита file_limit на большом каталоге: обмен рвётся без внятной ошибки, лечится либо увеличением лимита на сервере, либо включением приёма архивом.
- Задвоение заказов, потому что сайт не получил mode=success и продолжает отдавать один и тот же заказ при следующем query. Это первое, что проверяю, если 1С видит один заказ дважды.
- Расхождение цены на сайте и в 1С из-за нескольких типов цен, розничная, для сайта, акционная: в offers.xml может быть несколько блоков с ценой, и если сайт берёт не тот тип цены, витрина показывает неверную цифру.
- Таймауты при синхронном импорте на большом файле: процесс импорта может идти дольше, чем висит HTTP-запрос, и тогда 1С получает обрыв соединения, хотя импорт на сервере фактически довыполняется в фоне.
Если рядом с обменом нужно ещё продублировать уведомление о новом заказе в Telegram или CRM, обычно вешаю это отдельным вебхуком через n8n, а не встраиваю в сам механизм CommerceML. Так при сбое одной интеграции не падает вся синхронизация с 1С.
1С регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Какая редакция CommerceML актуальна и бывает ли версия 3.0?
1С публикует первую и вторую редакции стандарта плюс отдельный стандарт CommerceML EDI. Версии 3.0 среди них нет. На практике работают со второй редакцией: её актуальная XML-схема это 2.10, к ней на сайте 1С выложены лист изменений и описание схемы. Конфигурации 1С и модули CMS ориентируются на ту схему, под которую их писали, поэтому номер в атрибуте ВерсияСхемы у файлов обмена может отличаться.
Нужен ли программист для настройки обмена 1С с сайтом?
Для типового случая, одна CMS, один каталог, штатный плагин или встроенный модуль вроде того, что есть в Tilda, обмен можно поднять и без разработчика, следуя инструкции плагина. Программист нужен, когда каталог сложный, комплекты, вложенные характеристики, несколько складов с разными остатками, или когда обмен нужно встроить в нестандартную CMS, для которой готового модуля нет.
Можно ли передавать через CommerceML не только каталог, но и заказы?
Да, это штатная часть протокола, обмен заказами идёт отдельной сессией с параметром type=sale: сайт отдаёт 1С новые заказы, 1С обрабатывает их и может вернуть на сайт актуальный статус или номер документа. Так статусы в интернет-магазине синхронизируются с тем, что менеджер видит в 1С.
Как часто нужно запускать обмен между 1С и сайтом?
Каталог из import.xml обычно гоняю раз в сутки, ночью, потому что структура категорий и товаров меняется редко. Цены и остатки из offers.xml при активных продажах ставлю каждые 1-4 часа, а для магазинов с быстрым оборотом склада, где остаток может закончиться за час, есть смысл сокращать интервал до 15-30 минут. Заказы забираю в 1С чаще всего каждые 10-15 минут, чтобы менеджер видел новый заказ почти сразу.