CommerceML: как устроен обмен 1С с сайтом и где он ломается

CommerceML — это XML-формат, на котором 1С обменивается с интернет-магазином: товарами, ценами, остатками и заказами. Когда говорят «стандартный обмен 1С с сайтом», почти всегда имеют в виду именно его. Формат открытый, поэтому его понимают самые разные платформы. Отсюда и плюс, и минус: обмен подключается быстро, а ломается в тот момент, когда магазин перерастает типовую схему.

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

CommerceML: что это и из чего состоит обмен

Это не программа и не модуль, а договорённость сразу о двух вещах:

• формат — XML-файлы с классификатором, каталогом, предложениями и документами;
• протокол — порядок HTTP-запросов, которыми 1С передаёт файлы на сайт и забирает заказы.

Формат разработала фирма «1С», он описан в открытых спецификациях, к нему есть схема XSD. В обмене с сайтами обычно используют вторую версию формата; версия схемы указана в корневом элементе файла, и стоит смотреть именно туда, а не гадать по конфигурации.

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

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

Файлы CommerceML: import.xml, offers.xml, orders.xml

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

Ключ ко всей схеме — идентификатор Ид, обычно GUID. По нему сайт понимает, что это тот же товар, а не новый. Предложение с характеристикой получает Ид вида «Ид товара # Ид характеристики». Пока Ид стабилен, обмен обновляет записи. Как только он поменялся, для сайта это другой объект.

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

Как проходит один сеанс обмена 1С с сайтом

Ниже — общая последовательность на примере 1С-Битрикс; у других платформ логика та же, а детали отличаются. В адресе запроса обычно два параметра: type (catalog для каталога, sale для заказов) и mode (шаг). В Битриксе точка входа — скрипт вида /bitrix/admin/1c_exchange.php.

Каталог: type=catalog

1. checkauth. 1С отправляет логин и пароль пользователя сайта (обычная HTTP-аутентификация). Сайт отвечает success и отдаёт данные сессии: имя и значение cookie, которые 1С подставляет в следующие запросы.
2. init. 1С спрашивает условия. Сайт сообщает, принимает ли он архив zip и какой максимальный размер одной порции файла разрешён.
3. file. 1С передаёт файлы: XML и картинки, при необходимости архивом и порциями не больше заданного лимита. Сайт складывает их во временный каталог и на каждую порцию отвечает success.
4. import. 1С просит разобрать конкретный файл: сначала каталог, потом предложения. Сайт разбирает его шагами; пока работа не закончена, отвечает progress, и 1С повторяет запрос. В конце приходит success.
5. Завершающие шаги. В части реализаций есть дополнительные режимы, например деактивация товаров, которых нет в полной выгрузке. Их состав смотрите в документации платформы.

Заказы: type=sale

1. checkauth и init — как выше.
2. query. 1С просит заказы. Сайт отвечает XML с заказами, которые ещё не выгружены (в части реализаций — и с теми, что изменились после выгрузки).
3. 1С разбирает XML и создаёт или обновляет у себя документы заказа покупателя.
4. success. 1С сообщает, что заказы получены. Только после этого сайт помечает их выгруженными.
5. file и import. 1С отправляет на сайт файл с изменениями по заказам: статусы, оплата, отгрузка. Порядок шагов зависит от конфигурации 1С.

Самое хрупкое место — пара «получили заказы» и «подтвердили получение». Если связь оборвалась между ними, 1С заказы уже создала, а сайт об этом не знает и пришлёт те же заказы снова. Дальше всё решает, как принимающая сторона ищет дубли: по Ид заказа или по номеру.

И ещё одна особенность: ответы протокола текстовые (success, progress, failure и строка с сообщением). В типовой реализации сбой нередко приходит как обычный ответ с кодом 200 и словом failure в теле, поэтому мониторинг по кодам ответа его не заметит. Читайте тело ответа.

Что стандартный обмен делает хорошо

• Не нужно писать с нуля. Поддержка протокола уже есть в 1С и во многих платформах, в типовом случае это настройка, а не разработка.
• Файлы читаются глазами. XML можно открыть, посмотреть Ид, цену, остаток и понять, что именно пришло. Для разбора сбоев это большое преимущество.
• Порции и шаги. Передача по частям и импорт по шагам с ответом progress переживают долгие операции и лимиты на один запрос.
• Обмен в обе стороны. Каталог и цены идут на сайт, заказы — в 1С, статусы — обратно.
• Предсказуемость. Для типового магазина (один каталог, одна основная цена, один-два склада, умеренные требования к скорости) поведение обмена понятно заранее.

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

Жизненный цикл заказа через обмен

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

Выгрузка товаров из 1С на сайт: где формат упирается в пределы

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

• Одна модель каталога. 1С передаёт дерево групп, товары и свойства так, как они заведены в учёте. Сайту нужны свои рубрики, описания, SEO-поля, сопутствующие товары. Если не договориться, какие поля обновляет обмен, а какие ведут на сайте, ручные правки контента затрутся при очередной выгрузке. Настройка «что перезаписывать» зависит от платформы.
• Характеристики и торговые предложения. Размер и цвет в 1С — характеристики, на сайте — торговые предложения одного товара (или отдельные товары, в зависимости от платформы). Типичный сбой: характеристики в 1С включили позже, Ид предложений изменились, и сайт может создать дубли.
• Склады и типы цен. Файл предложений несёт все выбранные склады и типы цен, а что они значат для сайта, решает настройка соответствия. «Общий остаток» из нескольких складов — это правило (сумма? только основной склад? за вычетом резерва?), и его нужно записать.
• Большие каталоги и картинки. Один сеанс выгружает всё сразу. Чем больше каталог, тем ближе сеанс к лимитам времени и памяти, а картинки обычно самая тяжёлая часть выгрузки. Оборвался на середине — часть данных обновилась, часть нет, и узнать об этом можно только сверкой.
• Частичные обновления. В режиме «только изменения» в файл попадает то, что поменялось с прошлого сеанса. Если сайт принял файл, но разобрал не до конца, 1С может считать изменения доставленными, и сами они не повторятся. Поэтому полную выгрузку делают периодически, как страховку.
• Удаления. Скрытие или удаление товара в 1С не обязано убрать его с сайта: придёт ли признак удаления (в XML он может передаваться статусом товара) и что с ним сделает платформа, зависит от конфигурации и настроек. В полной выгрузке платформа может деактивировать товары, которых нет в файле, — но это настройка платформы, а не свойство формата. В частичной выгрузке отсутствие товара не значит ничего.
• Идентификаторы. Копия базы, перезаливка справочника, слияние дублей, второй источник товаров — всё это меняет или дублирует Ид. Это одна из самых дорогих «тихих» поломок: данные приходят, но не к тем записям.
• Нет квитанции по строкам. Ответ протокола относится к шагу целиком: success или failure. Формат передаёт текущее состояние заказа, а не историю правок. Ответ на вопрос «какая из тысяч позиций не прошла» даёт журнал платформы, а не формат.

Сбои обмена 1С с сайтом: симптом, причина, где смотреть

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

Как искать, когда симптома в таблице нет:

1. Сохраните сеанс целиком: время, файлы, ответы сайта. Следующий успешный сеанс сотрёт следы.
2. Определите шаг, на котором остановились: авторизация, передача, разбор каталога, разбор предложений, заказы. Это сразу сужает поиск.
3. Откройте журнал 1С и журналы сайта за то же время и сопоставьте записи. Не нашли ошибку на одной стороне — она на другой.
4. Откройте сам файл. Ищите конкретный товар или заказ по Ид, а не «что-то странное вообще».
5. Воспроизведите на копии. Исправление, проверенное только на боевых данных, — это следующий инцидент.

Когда остаться на CommerceML, а когда уходить

Выбор не «формат или API», а «что должно работать быстро и надёжно, а что может ходить пакетом». Чаще всего получается сочетание.

HTTP-сервисы — механизм самой платформы 1С:Предприятие 8: через них можно отдавать и принимать данные в нужной вам структуре, без файловых пакетов. Доступность и возможности зависят от релиза платформы, уточняйте для вашей версии.

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

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

Чек-лист перед запуском обмена 1С с сайтом

1. Распределить роли. Кто главный по каждому типу данных. Пример схемы: каталог и цены — 1С, контент — сайт, заказ до выгрузки — сайт, после — 1С. Ваша схема может быть другой, но записанной.
2. Записать правила. Какой тип цены уходит на сайт, какие склады складываются в остаток, что считается «доступно к заказу».
3. Проверить Ид. Нет ли дублей номенклатуры, один каталог — один источник, Ид не пересоздавались при переносах.
4. Развернуть тестовый контур. Копия 1С, копия сайта, отдельный домен (см. примечание ниже).
5. Прогнать полную выгрузку на реальном объёме, а не на десяти товарах: время, память, размер порций.
6. Согласовать лимиты. Размер загрузки и время выполнения скрипта на сайте, размер тела запроса и тайм-ауты у прокси и веб-сервера, размер порции, которую назначает сайт.
7. Сопоставить статусы, способы оплаты и доставки сайта с видами в 1С. Прогнать заказ каждого вида: онлайн-оплата, оплата при получении, самовывоз, доставка, скидка, комплект.
8. Проверить сценарии с изменениями: правка заказа после выгрузки, отмена, частичная отгрузка, возврат.
9. Включить журналы в 1С и на сайте и решить, кто их читает и сколько хранятся.
10. Сделать резервную копию боевого сайта перед первой полной выгрузкой и описать, как вернуться назад.
11. Настроить мониторинг: результат и длительность каждого сеанса, давность последнего успешного, оповещение при пропуске.

Сверка: как узнать, что обмен не врёт

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

Условный пример (числа условные): в 1С четыре тысячи активных товаров, на сайте на десять меньше. Отчёт «десять расхождений» бесполезен. Нужен список из десяти Ид с названиями и причиной каждой: отсутствует на сайте, отключён, продублирован. Число без списка ничего не даёт.

Что делаем мы: разбор обмена 1С с сайтом

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

Ориентиры по стоимости (по тарифам, не фиксированная смета): обследование обмена — от 200 000 ₽ за один-два процесса, 2–3 недели; сумма вычитается из следующего этапа. Типовой обмен 1С — 150 000–350 000 ₽, базовый односторонний обмен — от 150 000 ₽. Всё сделанное остаётся у вас по акту: исходники, конфигурации и журналы. Работаем в вашем контуре и вашем репозитории, договорённости фиксируем письменно до начала работ, а в конце каждого этапа вы вправе остановиться.