Типовые ошибки обмена с 1С

Обмен с 1С ломается предсказуемо. В 90% случаев причина — не «глюк Битрикса», а таймаут, неверная привязка свойств, права на каталог или расхождение версий протокола CommerceML. Ниже — типовые ошибки и порядок их устранения.

Как устроен обмен и где он ломается

Обмен между 1С и сайтом идёт по протоколу CommerceML 2 через точку входа /bitrix/admin/1c_exchange.php. 1С поочерёдно вызывает этапы checkauth, init, file и import, передавая XML-файлы import.xml (каталог) и offers.xml (торговые предложения, цены, остатки). На стороне сайта работает модуль catalog, а разбор файлов — компонент bitrix:catalog.import.1c.

Сбой возникает на любом из этапов, и важно понимать, где именно. Первым делом смотрите:

• журнал обмена в 1С (окно «Обмен с сайтом»);
• Рабочий стол → Настройки → Инструменты → Диагностика ошибок в админке Битрикс;
• файлы выгрузки во временной папке /upload/1c_catalog/.

Ошибки авторизации и прав доступа

Самая частая «стена» — обмен не проходит этап checkauth. В журнале 1С видно «Ошибка авторизации» или пустой ответ вместо строки success. Причины и что проверять:

Таймауты и обрыв на больших выгрузках

Каталог на 50–100 тысяч позиций почти всегда упирается в лимиты PHP. Симптом — обмен «висит» и обрывается, в логе «Превышено максимальное время выполнения» или белый экран. Работать нужно по двум фронтам — дробление и лимиты.

1. В настройках выгрузки в 1С включите пошаговую выгрузку и ограничьте объём файла (например, 1 Мб). Тогда 1С шлёт данные порциями, а не одним гигантским XML.
2. На сайте увеличьте параметры в .htaccess или php.ini: max_execution_time, memory_limit (от 512M), post_max_size и upload_max_filesize.
3. В настройках модуля задайте «Интервал сохранения» и «Максимальное время выполнения шага» меньше серверного лимита — тогда Битрикс сам разобьёт импорт на шаги.

Если сервер за nginx, проверьте client_max_body_size — иначе большой offers.xml вернёт 413 Request Entity Too Large ещё до PHP.

Дубли товаров и слетевшая привязка

После обмена в каталоге появляются задвоенные товары или создаётся новый раздел вместо обновления старого. Корень проблемы — идентификация элементов. Битрикс сопоставляет товар из 1С с элементом инфоблока по внешнему коду XML_ID, который берётся из Ид в XML.

• Если в 1С перезаливали номенклатуру или меняли GUID, внешние коды не совпадут — Битрикс создаст дубли.
• Если импорт руками (CSV) перезаписал XML_ID, следующая выгрузка из 1С не найдёт «свои» элементы.
• Разделы двоятся, когда группы номенклатуры в 1С получили новые идентификаторы.

Лечение: не менять XML_ID вручную; при миграции — выгрузить соответствие «Ид 1С ↔ XML_ID» и восстановить его. Для разовой чистки помогает выгрузка каталога в CSV, дедупликация по внешнему коду и повторная привязка.

Не обновляются свойства, цены и остатки

Обмен «зелёный», но на витрине старые цены или пустые характеристики. Здесь виноват не сам обмен, а сопоставление данных.

• Свойства не заполняются — в 1С характеристика не выгружается как свойство CommerceML, либо в инфоблоке нет свойства с совпадающим кодом. Битрикс создаёт свойства автоматически по первому обмену; если инфоблок настроили заранее с другими кодами — совпадения не будет.
• Цены не меняются — тип цены в 1С не сопоставлен с типом цены каталога. Проверьте раздел Магазин → Настройки → Типы цен и соответствие имён.
• Остатки нулевые — в 1С не включена выгрузка остатков по складам, либо на сайте не включён учёт по складам, а данные приходят складские.

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

Сбои встречной выгрузки заказов

Обмен двусторонний: сайт отдаёт заказы в 1С файлом orders, 1С возвращает статусы и номера. Типовые проблемы этого направления:

• Заказы не уходят в 1С — в настройках модуля выключен обмен заказами, либо у заказа статус, не попадающий в фильтр выгрузки.
• Товар в заказе не находится — 1С не может сопоставить позицию по XML_ID (тот же корень, что у дублей каталога).
• Двойное списание остатка — резервирование ведётся и на сайте, и в 1С без согласования правил.
• Не подтягиваются свойства покупателя — свойства заказа на сайте не сопоставлены с реквизитами контрагента в 1С.

Порядок диагностики: чек-лист

Чтобы не гадать, идите по этапам обмена сверху вниз. Такой порядок закрывает большинство инцидентов за один заход:

1. Смотрим журнал в 1С — на каком этапе (checkauth/init/file/import) обрыв.
2. Открываем детальный лог модуля и «Диагностику ошибок» в админке.
3. Проверяем права пользователя обмена и исключения проактивного фильтра.
4. Смотрим лимиты PHP/nginx и размер файлов в /upload/1c_catalog/.
5. Сверяем XML_ID, типы цен и коды свойств — то, что чаще всего «не сходится».
6. Повторяем обмен с одним товаром — так проще локализовать проблему.

Ведите изменения по одному: поменяли параметр — прогнали обмен — зафиксировали результат. Массовые правки «на всякий случай» только запутывают картину.

Итог

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

Когда каталог большой, а обмен двусторонний и нагруженный, мы в B2Bsite настраиваем CommerceML «под ключ»: чиним привязку номенклатуры, разбиваем выгрузку на шаги, согласуем цены, склады и статусы заказов, а затем ставим обмен на регулярный мониторинг, чтобы сбой было видно раньше, чем его заметит клиент.