Обмен с сайтом 1С Битрикс: пошаговая настройка узла и импорта

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

У клиента с каталогом около 30 000 SKU импорт регулярно вставал на середине: один обработчик события падал с ошибкой и ронял всю партию. Товары успевали записаться частично, оставшиеся не доезжали до сайта. Разбираться пришлось не с «1С сломалась», а с тем, как именно устроен протокол обмена и где в нём точка, в которой падение обработчика убивает весь шаг. Когда к нам приходят с такой задачей — «импорт идёт, но не доходит» или «половина товаров обновилась, половина нет», — первым делом мы смотрим не настройки узла, а на сам механизм: кто инициатор, что за формат, как данные физически попадают на сайт.

Штатный обмен с сайтом 1С — это не «выгрузка файла по FTP», а протокол, который разработали «1С» и «1С-Битрикс» совместно. Инициатором обмена выступает система «1С:Предприятие»: именно она стучится на сайт, а не наоборот. Данные передаются по стандарту CommerceML 2 — открытому XML-стандарту обмена коммерческой информацией, — а сам XML сжимается в ZIP-архив, чтобы файлы не раздувались до десятков мегабайт на больших каталогах. Понимание этой связки «инициатор — формат — упаковка» объясняет почти все дальнейшие грабли: почему импорт порционный, почему обработчики стреляют не там, где ждёшь, и почему падение на одном шаге откатывает всю партию.

Разберём роли сторон. 1С формирует архив с XML внутри: корневой файл import.xml несёт информацию о группах и разделах каталога, типах цен и самих товарах. Сайт принимает этот архив через скрипт обмена — на стороне Битрикса это компонент catalog.import.1c, который разбирает ZIP, читает XML и раскладывает данные по инфоблокам.

Сам протокол — пошаговый, и часть шагов имеет собственные имена. На этапе «Авторизация на сайте» учётная система получает ключ сессии. На этапе «Инициализация» она обращается к ресурсу по адресу из настройки обмена — параметр <Адрес_скрипта> — и сообщает сайту версию CommerceML; в запросе используется <Ключ_сессии>, полученный на авторизации. Заголовок запроса при этом формируется как "Cookie: " + ..., то есть сессия держится на cookie, а не на перелогине на каждом шаге.

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

Настройка обмена Битрикс: узлы, права и журнал

Типичный сценарий: сайт уже собирает заказы, 1С уже выгружает каталог, а менеджеры жалуются, что цены и остатки на витрине разошлись с учётной системой. Прежде чем лезть в код, убедитесь, что сам обмен настроен и включён на стороне Битрикса. Штатный обмен по CommerceML живёт в модулях торгового каталога и интернет-магазина, а они входят в редакции начиная с «Малого бизнеса». В «Старте» и «Стандарте» уроки по интеграции помечены в документации 1С-Битрикс как недоступные — модулей там просто нет, и никакие настройки узлов не появятся, пока редакция не поднята.

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

1. Открыть Настройки > Настройки продукта > Настройки модулей > Интернет-магазин и перейти на закладку «Экспорт в 1С:Предприятие».
2. В форме «Настройка параметров обмена» создать узел обмена, задать режим обмена данных и отметить опцию «Активировать обмен документами», если нужны заказы, а не только каталог.
3. Проверить версию модуля обмена 1С-Битрикс и открыть лог узла за нужную дату кнопкой «Открыть лог».

Форма «Настройка параметров обмена» — это рабочее место администратора обмена. Разберём, что делает каждый элемент и когда он нужен.

Почему мы всегда начинаем с лога, а не с кода? Журнал узла показывает, на каком именно шаге обмен оборвался: авторизация, инициализация, разбор XML, запись в инфоблок. Пока не видно этой точки, любые правки в обработчиках событий — стрельба вслепую. Можно чинить импорт каталога, когда не проходит экспорт заказов, или наоборот.

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

Пошаговая настройка 1С: страница импорта и компонент catalog.import.1c

Самая частая ошибка при первом знакомстве с обменом — попытка «просто положить файл рядом». Логика кажется очевидной: 1С выгружает архив, значит достаточно указать ей папку на сайте, куда складывать данные, и дело сделано. На практике так не работает. Обмен идёт не файлами на диске, а HTTP-запросами, и на стороне сайта должен быть адрес, который эти запросы принимает и обрабатывает. Именно поэтому вся пошаговая настройка 1С на стороне Битрикса сводится к одной странице с компонентом импорта — она становится точкой входа для учётной системы. Дальше 1С сама инициирует обмен, шлёт запросы на этот адрес и получает ответы. Всё, что от нас требуется, — создать страницу, разместить на ней штатный компонент и убедиться, что узел обмена настроен.

В проектах с активным импортом эта страница — самое нагруженное место на сайте. Поэтому к её созданию стоит подойти аккуратно, а не «накидать компонент в первый попавшийся раздел».

1. Создать страницу импорта — например, catalog_import.php в корне сайта или в отдельном служебном разделе. Адрес этой страницы потом указывается в настройках обмена на стороне 1С, поэтому лучше сразу выбрать понятный путь и не менять его без необходимости.
2. Разместить на странице компонент «Импорт каталога из 1С» (bitrix:catalog.import.1c). В визуальном редакторе он лежит по пути Контент > Каталог > Импорт каталога из 1С. Это стандартный компонент из дистрибутива модуля торгового каталога — писать его с нуля не нужно.
3. Убедиться, что доступен раздел «Обмен с 1С» (Контент > Обмен с 1С) — там живут компоненты обмена в формате CommerceML v2. Если раздела нет, скорее всего не установлен нужный модуль или редакция ниже «Малого бизнеса».

Минимальный вызов компонента в catalog_import.php выглядит так:

<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");

$APPLICATION->IncludeComponent(
    "bitrix:catalog.import.1c",
    "",
    array(
        "IBLOCK_TYPE" => "catalog",        // замените на тип вашего инфоблока
        "INTERVAL"    => "30",             // интервал одного шага в секундах
    ),
    false
);

require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");

Как читать этот код. Ключевых параметров, которые реально влияют на импорт, немного. INTERVAL управляет тем, сколько секунд компонент работает в рамках одного шага: обмен идёт порциями, и на больших каталогах это критично — один длинный запрос упадёт по таймауту, а несколько коротких пройдут. Данные сжимаются ZIP-форматом, что позволяет заметно уменьшить объём XML-файлов, передаваемых по сети. Внутри архива лежит import.xml — корневой файл с информацией о группах и разделах каталога и о типах цен. Именно с него начинается разбор данных, и если он не читается, дальше импорт не пойдёт.

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

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

Многие думают, что «интеграция с 1С» — это один сценарий: настроил узел, нажал «Обмен», получил товары на витрине. В проектах мы всегда настраиваем как минимум два типа обмена, и у них разное назначение. Обмен товарами (type=catalog) наполняет каталог — разделы, товары, торговые предложения, цены. Обмен справочниками (type=reference) создаёт и обновляет на сайте HL-блоки: склады, типы оплаты, характеристики, любые служебные списки, которые 1С ведёт как источник правды.

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

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

Как выбирать тип под задачу — вопрос не «какой лучше», а «что нужно получить на сайте». Если цель — витрина с товарами, ценами и остатками, это обмен товарами. Если нужны HL-блоки с настройками, которые потом читает код шаблона или обработчик, — обмен справочниками.

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

Отдельно стоит помнить про поля типа «Булево». В обмене справочниками они приходят строками true или false, а иногда пустой строкой. Если вы ждёте bool и пишете его в HL-блок напрямую, пустая строка превратится в false и затрёт реальное значение. Приводите тип явно в своём обработчике.

Обмен данными 1С: компоненты, порции и интервал шага

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

Первый — bitrix:catalog.import.1c. Он принимает от 1С архив в формате CommerceML 2, разбирает import.xml и раскладывает данные по инфоблокам: разделы, товары, типы цен, свойства. Второй — bitrix:sale.export.1c. Он работает в обратную сторону: собирает заказы с сайта и отдаёт их учётной системе. Один компонент — вход каталога, второй — выход заказов. В типовой конфигурации они живут на разных страницах, каждая со своим узлом обмена.

Дальше — перечень того, с чем вы будете работать при настройке.

• bitrix:catalog.import.1c — импорт каталога из 1С: разделы, товары, цены, остатки, свойства.
• bitrix:sale.export.1c — экспорт заказов сайта в 1С для дальнейшей обработки в учётной системе.
• catalog.import.1c в разделе «Обмен с 1С» — стандартный компонент из дистрибутива модуля, отдельно ставить его не нужно.

Оба компонента вызываются по одному протоколу, но с разными типами обмена: type=catalog для товаров, type=reference для справочников (HL-блоков). Подробно об этом говорили выше, в секции про интеграцию.

Теперь про то, что чаще всего сбивает с толку при первом запуске, — про порции.

Обмен не выполняется одним длинным запросом. Он разбит на шаги, и каждый шаг — отдельный HTTP-запрос, который живёт несколько секунд. Между шагами 1С получает ответ и решает, продолжать ли. Управляет этим параметр «Интервал одного шага в секундах» в настройках узла обмена.

Зачем так сделано? Представим каталог на 30 000 SKU: разбор XML, обновление цен, пересчёт свойств — всё это в одном запросе упрётся в max_execution_time и memory_limit на любом хостинге. Порционный обмен защищает от таймаутов: сессия не держится открытой часами, а аккуратно продлевается шаг за шагом. Это не «медленность» Битрикса, а осознанный компромисс ради живучести на больших каталогах.

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

Свой обработчик обмена: перенос из 1c_exchange.php в /local/

Штатный обмен закрывает 90% сценариев, но иногда его не хватает. Скажем, нужно на этапе импорта отфильтровать часть товаров по внешнему признаку, сходить в сторонний API за актуальным остатком, записать в HL-блок журнал изменений или разослать уведомление менеджерам о новых позициях. Штатный обработчик такие вещи не делает — и тогда мы собираем собственный обменник, который повторяет логику системного, но с нашими доработками.

Ключевое правило: такой обработчик живёт в /local/, а не в ядре. Ниже — скелет точки входа и как перенести логику из системного скрипта без правок модуля.

<?php
// /local/php_interface/init.php

use Bitrix\Main\EventManager;

EventManager::getInstance()->addEventHandler(
    'main',
    'OnBeforeProlog',
    'registerCustomExchangeHandler'
);

function registerCustomExchangeHandler(): void
{
    $requestUri = $_SERVER['REQUEST_URI'] ?? '';

    // Ловим только свой эндпоинт обмена, чтобы не мешать штатному
    if (strpos($requestUri, '/local/exchange/1c/') !== 0) {
        return;
    }

    // Отдаём управление нашему скрипту вместо системного компонента
    $handler = $_SERVER['DOCUMENT_ROOT'] . '/local/exchange/1c/handler.php';
    if (file_exists($handler)) {
        require_once $handler;
        exit;
    }
}

Как переносить саму логику: код штатного обработчика лежит в /bitrix/modules/sale/admin/1c_exchange.php. Его можно скопировать в /local/exchange/1c/handler.php и заменить вызов системного компонента bitrix:catalog.import.1c на собственный — тот, что делает нужные вам проверки и интеграции. Такой подход повторяет то, что делает сам модуль, но оставляет вам полный контроль над каждым шагом импорта.

Важно понимать, почему правки прямо в /bitrix/modules/ — это тупик. При обновлении платформы Битрикс перезаписывает файлы модулей целиком. Все ваши изменения молча исчезнут. Хуже того — исчезнут не сразу, а в момент обновления, когда вы уже забыли, что там что-то правили. Через месяц выяснится, что обмен снова работает по-старому, а причина неочевидна. Поэтому вся кастомизация — только в /local/: этот каталог платформа не трогает никогда.

Второй момент — где именно регистрировать точку входа. Для простых проектов достаточно init.php. Если доработок много, логичнее вынести их в собственный модуль с module.php и include.php: тогда обработчики регистрируются при подключении модуля, а не на каждом хите. Для тяжёлых сценариев, которые не обязаны выполняться синхронно с обменом, лучше использовать агенты или очередь.

Самые частые ошибки, которые ломают импорт из 1С

Распространённая ошибка: считать, что если обмен настроен один раз, он будет работать «как часы» годами. На практике импорт ломается не от сложных сценариев, а от пяти-шести грабель, которые повторяются в проекте за проектом. У магазинов с активным импортом эти грабли вылезают особенно быстро. Каталог обновляется несколько раз в день, менеджеры параллельно правят карточки: обмен уже прошёл, а на витрине половина цен не та, часть товаров пропала, заказы висят с непересчитанной суммой.

Хорошая новость: все эти сбои диагностируются по логу узла обмена. Штатная форма настроек даёт один инструмент — кнопку «Открыть лог», которая показывает файл с логами обмена для выбранного узла за конкретную дату. Мы в своей практике начинаем любой разбор поломки именно с неё, а не с дебага на проде.

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

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

Отдельно про правки в /bitrix/modules/. Это самая коварная грабля: код работает, пока не прилетит обновление модуля, и затирается без предупреждения. Мы регулярно видим такие правки у магазинов, которые настраивали обмен давно и «на коленке». Переносить их нужно в /local/, а обработчики регистрировать через EventManager. Подробно разбирали это в секции про свой обработчик обмена.

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

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

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

Чеклист, который у нас прижился:

• Редакция Битрикса — не ниже «Малого бизнеса»: штатный обмен живёт в модулях торгового каталога и интернет-магазина, в «Старте» и «Стандарте» этих модулей нет.
• Страница с компонентом bitrix:catalog.import.1c создана и открывается без ошибок — например, catalog_import.php в корне сайта.
• Узел обмена настроен: адрес сайта, логин, пароль, привязка к инфоблоку каталога.
• Опция «Активировать обмен документами» отмечена — но только если планируется выгрузка заказов из 1С на сайт.
• Кнопка «Открыть лог» в форме настроек узла открывает файл — значит, модуль обмена видит директорию логов и имеет туда права на запись.
• В /bitrix/modules/ нет правок — если что-то дописывали, перенесите в /local/ до запуска, иначе первое же обновление модулей затрёт ваши изменения.

Почему мы вообще настаиваем на порядке «редакция и модули → страница и компонент → узел»? Потому что диагностика обмена идёт снизу вверх, а настройка — сверху вниз. Когда всё настроено правильно, но обмен не идёт, мы смотрим лог. А лог может быть пустым по трём совершенно разным причинам: модуля нет, страница отдаёт 404, или узел не сохранён.

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

Обратный порядок тоже встречается: администратор проверяет всё по списку, запускает обмен, видит пустой лог и решает, что «модуль не работает». модуль работает, просто узел обмена не активирован или в настройках указан не тот адрес скрипта. Проверка в правильной последовательности отсекает эти ложные ветки и оставляет одну реальную причину.