Интеграция 1С с сайтом: как идёт обмен и где рвётся

Интеграция 1С с сайтом: не кнопка "синхронизировать", а серия HTTP-запросов по расписанию, где 1С выступает инициатором, а сайт отвечает по строго заданному протоколу. Понимание этой последовательности решает половину проблем: когда обмен встаёт, вопрос звучит не "почему не работает", а "на каком из четырёх шагов оборвалось".

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

Один цикл обмена: четыре запроса#

Обмен инициирует 1С. Она обращается к скрипту на сайте, который по традиции называется 1c_exchange.php, и передаёт в параметрах, что именно происходит: в type каталог или заказы, в mode шаг обмена.

Шаг первый, авторизация. Запрос с type=catalog&mode=checkauth. Сайт отвечает тремя строками: слово success, имя Cookie и его значение. Все последующие запросы 1С шлёт с этим Cookie в заголовке. Если авторизация не прошла, обмен даже не начнётся, и это самая простая для диагностики ошибка.

Шаг второй, параметры. Запрос с mode=init. Сайт возвращает две строки: поддерживает ли он архивы (zip=yes или zip=no) и file_limit, максимальный размер файла в байтах, который он готов принять за один запрос. Именно здесь закладывается будущая проблема больших каталогов: если сайт назовёт лимит в мегабайт, а выгрузка весит сто, файл будет разрезан на сотню частей.

Шаг третий, передача файлов. Запросами с mode=file&filename=<имя> система передаёт содержимое файлов методом POST. Формат: CommerceML 2, тот самый XML с русскими тегами, где корневой элемент называется КоммерческаяИнформация, а версия схемы указывается атрибутом (в текущих выгрузках это 2.08).

Шаг четвёртый, разбор. Запросами с mode=import&filename=<имя> сайт пошагово читает загруженное и создаёт у себя товары, свойства, цены и картинки. Слово "пошагово" здесь ключевое: скрипт обрабатывает порцию, отвечает "progress", и 1С зовёт его снова. Сотня тысяч предложений: сотни таких вызовов.

Цикл обмена 1С с сайтом: четыре запроса на выгрузку каталога и четыре на приём заказов

Заказы идут обратно#

Вторая половина обмена: заказы с сайта в 1С. Тип меняется на sale, а последовательность становится другой.

После тех же checkauth и init система отправляет запрос с mode=query. В ответ сайт отдаёт заказы всё в том же CommerceML. Когда 1С записала их у себя, она подтверждает приём запросом с mode=success: до этого момента заказы для неё не приняты, и при обрыве связи они придут снова.

Что происходит с заказом внутри 1С, стоит знать до того, как менеджеры увидят результат:

• заказу присваивается категория "Заказ с сайта", сохраняются его номер и дата с сайта;
• контрагент ищется по ИНН или по наименованию: что именно используется, зависит от настроек загрузки;
• договор ищется среди существующих договоров с клиентом, и если подходящего нет, создаётся новый;
• свойства заказа ищутся по наименованию, а если свойства с таким названием нет, оно создаётся автоматически.

Последний пункт: источник самого неприятного мусора. Переименовали поле на сайте с "Комментарий" на "Комментарий к заказу": в 1С появилось новое свойство, и старые заказы остались со старым. Через полгода в справочнике десяток почти одинаковых названий, и никто не помнит, какое живое.

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

Что лежит внутри файла обмена#

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

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

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

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

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

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

Шесть мест, где обмен рвётся#

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

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

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

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

Дубли свойств и характеристик. Свойства сопоставляются по наименованию. Любое переименование в 1С или на сайте создаёт вторую сущность вместо обновления первой. Через несколько месяцев фильтр на сайте показывает два цвета "Чёрный", и оба с товарами.

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

Расписание, которое накладывается само на себя. Обмен раз в 15 минут при длительности в 20 минут: два одновременных обмена, гонка за одни и те же данные и заблокированные таблицы. Лечится не учащением расписания, а предохранителем: пока предыдущий процесс не закончил, новый не стартует.

Интеграция 1С с сайтом не на Битриксе#

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

Что придётся сделать на своей стороне:

1. Написать обработчик четырёх режимов протокола и отдавать ответы ровно в том виде, который ждёт 1С, включая три строки при авторизации.
2. Разобрать CommerceML: номенклатура, характеристики, единицы измерения, цены нескольких типов, остатки по складам.
3. Придумать устойчивое сопоставление товаров. Не по названию и не по артикулу: по идентификатору из 1С, который не меняется при переименовании.
4. Сделать разбор пошаговым и устойчивым к обрыву: обработали порцию, запомнили место, ответили "progress".
5. Собрать обратную выгрузку заказов в том же формате.

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

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

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

Семь проверок на тестовом контуре, каждая ловит свой класс ошибок.

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

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

Наш порядок первого обмена#

Первый обмен всегда собираем на копии реального каталога, а не на демонстрационных данных: только там видны настоящие объёмы, дубли свойств и кривые единицы измерения. Дальше: предохранитель от наложения запусков, разделение расписаний (остатки часто, полный каталог ночью) и уведомление в Telegram, когда цикл не завершился.

Работы такого рода ведём в рамках разработки интернет-магазина или отдельным проектом по автоматизации: прототип обмена на тестовом контуре занимает 1-2 недели и стоит фиксированные 35-100 тысяч рублей, дальше подключение к боевым данным и месяц сопровождения, пока выправляются пограничные случаи. Потом магазин можно оставить на обслуживании от 5 900 рублей в месяц, чтобы обмен кто-то смотрел.

После первого удачного обмена стоит проверить, что каталог из 1С не сломал сайт для поиска: типовая выгрузка любит плодить дубли и пустые описания. Быстрый способ увидеть это со стороны: бесплатный аудит по 17 маркерам, он показывает индексацию и заголовки страниц без регистрации.

Что спросить до начала работ#

Пять вопросов, которые экономят месяц.

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

Сколько типов цен и складов участвует в обмене? Розница, опт, склад магазина и склад маркетплейса: разные ветки логики, а не "ещё одно поле".

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

Как поступать с товаром, который пропал из выгрузки: снимать с публикации, скрывать или удалять? Ответ "удалять" почти всегда неверный: одна сбойная выгрузка, и каталог пуст.

Кто и по какому сигналу узнаёт, что обмен не прошёл? Без уведомления вы узнаете об остановке от клиента, который заказал отсутствующий товар.

Источники#

• Протокол обмена с сайтом: описание шагов обмена и форматов ответов, 1С
• Стандарты CommerceML: схемы и версии формата