Ошибки обмена 1С-Битрикс: как найти причину и восстановить синхронизацию

1С не подключается к сайту. Файлы передаются, но импорт останавливается. Товары обновляются, а цены или остатки — нет. Заказы не попадают в 1С. После обмена появляются дубли. Большая выгрузка прерывается, хотя маленькая проходит нормально.

У всех этих ситуаций разная диагностика.

Поэтому начинать лучше не с переустановки модуля обмена или полной выгрузки каталога, а с вопроса:

на каком именно этапе обмен перестаёт работать правильно?

В стандартной интеграции данные передаются в формате CommerceML. Если определить последний успешно выполненный этап, область поиска обычно сокращается очень быстро.

Если обмен нужен прямо сейчас

Если рабочий магазин перестал синхронизироваться:

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

Главный принцип:

определили этап → получили фактическую ошибку → исправили причину → повторили тот же обмен.

Содержание

1. Как устроен обмен 1С с 1С-Битрикс
2. Сначала определяем, где остановился обмен
3. 1С не подключается к сайту
4. Авторизация проходит, но обмен дальше не идёт
5. Файл передался, но импорт завершился ошибкой
6. Товары не появляются или обновляются неправильно
7. Не обновляются цены
8. Не обновляются остатки
9. Появляются дубли товаров и предложений
10. Не передаются заказы
11. Обмен обрывается на больших файлах
12. Проверяем серверные ошибки и пользовательский код
13. Полный и обмен изменениями
14. Проверка после исправления
15. Частые вопросы

1. Как устроен обмен 1С с 1С-Битрикс

Стандартный обмен каталога между 1С и 1С-Битрикс использует формат CommerceML v2.

Упрощённо процесс можно представить так:

1С → подключение к сайту → авторизация → подготовка параметров обмена → передача файлов → обработка CommerceML → товары / предложения → цены → остатки

Для заказов направление может быть другим:

сайт → данные заказов → CommerceML → 1С

В реальной настройке обмен может включать не все перечисленные данные.

Например, отдельно настраиваются:

• товары;
• торговые предложения;
• свойства;
• изображения;
• цены;
• остатки;
• склады;
• документы.

Поэтому сообщение «товары выгрузились» ещё не означает, что весь обмен завершился правильно.

Цена и остаток могут обрабатываться на других этапах и по другим настройкам.

↑ К оглавлению

2. Сначала определяем, где остановился обмен

До изменения настроек нужно найти последний успешный этап.

Удобно разделить диагностику на четыре части.

Этап 1. Подключение

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

Если ошибка появляется здесь, CommerceML ещё может вообще не участвовать в проблеме.

Проверяем:

• адрес сайта;
• HTTPS;
• DNS;
• доступность сайта с компьютера или сервера 1С;
• авторизацию;
• пользователя обмена;
• блокировки со стороны веб-сервера или защитного ПО.

Этап 2. Передача файла

Подключение уже работает, но сайт должен принять XML или архив обмена.

Если сбой возникает здесь, проверяем:

• размер данных;
• свободное место;
• возможность записи;
• ограничения сервера;
• сетевые обрывы;
• ответ веб-сервера.

Этап 3. Импорт

Файл уже находится на стороне сайта, но 1С-Битрикс должен разобрать CommerceML и применить данные.

Проверяем:

• структуру XML;
• конкретный файл обмена;
• PHP;
• базу данных;
• пользовательские обработчики;
• фатальные ошибки;
• настройки импорта.

Этап 4. Результат

Сам обмен формально завершён, но данные выглядят неправильно.

Например:

• цена осталась старой;
• остаток не изменился;
• предложение не связано с товаром;
• появились дубли;
• заказ не попал в 1С.

Это уже не ошибка передачи файла. Здесь проверяются настройки, идентификаторы и содержимое CommerceML.

↑ К оглавлению

3. 1С не подключается к сайту

Если обмен останавливается ещё на проверке соединения, сначала проверяем сам доступ к сайту.

Не нужно сразу разбирать import.xml: файл ещё мог не передаваться.

Проверяем адрес

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

Особенно внимательно смотрим ситуацию после:

• перехода с HTTP на HTTPS;
• смены домена;
• добавления www;
• переноса сайта;
• изменения прокси или CDN;
• изменения правил редиректа.

Если 1С обращается к одному URL, а сервер перенаправляет запрос на другой, важно посмотреть фактическую цепочку HTTP-ответов.

Проверяем пользователя обмена

Пользователь должен существовать на сайте и иметь необходимые права для операции обмена.

Если пароль менялся или пользователь заблокирован, соединение перестанет работать даже при полностью исправном CommerceML.

Проверяем HTTP-ответ

Вместо ожидаемого служебного ответа сервер может вернуть:

• страницу авторизации;
• HTML страницы ошибки;
• 403 Forbidden;
• 404 Not Found;
• 500 Internal Server Error;
• редирект;
• защитную страницу.

В таком случае проблема находится раньше импорта каталога.

Сначала исправляем HTTP-доступ, затем повторяем обмен.

↑ К оглавлению

4. Авторизация проходит, но обмен дальше не идёт

Иногда проверка соединения завершается успешно, но следующий этап останавливается.

Это уже важная локализация:

логин и пароль работают, сайт доступен, проблема находится дальше.

Проверяем сообщение 1С и серверный журнал в момент следующего запроса.

Причиной могут быть:

• ошибка PHP;
• неправильный ответ сервера;
• модификация служебного ответа пользовательским кодом;
• блокировка определённого запроса;
• проблема с сессией;
• ошибка модуля;
• серверное ограничение.

Служебный обмен ожидает определённый формат ответа.

Поэтому даже лишний вывод PHP-кода до штатного ответа способен нарушить протокол.

Например, опасны:

• echo;
• print_r;
• var_dump;
• PHP warning;
• HTML от обработчика ошибки.

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

При диагностике проверяем не только HTTP-код, но и фактическое тело ответа.

↑ К оглавлению

5. Файл передался, но импорт завершился ошибкой

Если файл успешно дошёл до сайта, подключение и передача уже не являются основной проблемой.

Теперь проверяем обработку данных.

Первое действие — получить точную серверную ошибку за время импорта.

Ищем:

• PHP Fatal error;
• Uncaught Error;
• исключение;
• ошибку SQL;
• нехватку памяти;
• превышение времени выполнения;
• Permission denied;
• No space left on device;
• сообщение пользовательского обработчика.

Проверяем сам CommerceML

Если сервер не показывает фатальную ошибку, полезно сохранить проблемный XML и определить:

• какой файл обрабатывался;
• какой элемент был последним;
• корректная структура XML или нет;
• присутствует нужный товар;
• какие идентификаторы переданы;
• передана цена;
• передан остаток.

Сам файл обмена часто отвечает на вопрос быстрее, чем настройки административной панели.

Например, если в CommerceML вообще нет новой цены, искать причину в компоненте каталога сайта преждевременно.

Сначала выясняем, почему 1С её не сформировала.

↑ К оглавлению

6. Товары не появляются или обновляются неправильно

Ситуация:

обмен завершён без явной ошибки, но товар на сайте не появился или не изменился.

Проверяем по цепочке.

Товар попал в CommerceML

Сначала ищем его в выгруженном XML.

Если товара там нет, проблема находится на стороне отбора и настроек выгрузки 1С.

Проверяем:

• выбранный каталог;
• фильтр номенклатуры;
• настройки узла обмена;
• режим выгрузки изменений;
• фактические изменения товара.

Товар есть в XML

Тогда смотрим:

• идентификатор;
• группу;
• свойства;
• предложение;
• существующий элемент на сайте;
• настройки инфоблока;
• результат импорта.

Особенно важен внешний идентификатор.

Именно устойчивые идентификаторы позволяют обмену понимать, какой объект сайта соответствует объекту из 1С.

Если эти связи нарушены, система может не найти существующий товар или создать другой.

Проверяем пользовательский код

В проекте могут быть обработчики событий, которые:

• меняют поля товара;
• запрещают сохранение;
• изменяют активность;
• преобразуют свойства;
• создают дополнительные элементы.

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

↑ К оглавлению

7. Не обновляются цены

Товар может обновляться нормально, а цена оставаться старой.

Это отдельная диагностическая ветка.

Сначала открываем CommerceML и проверяем, какая цена реально пришла.

Цена отсутствует в файле

Проверяем настройки выгрузки на стороне 1С:

• включена передача цен;
• выбран нужный прайс;
• нужный тип цены попадает в обмен;
• товар входит в текущую выгрузку.

Цена присутствует

Тогда проверяем сайт:

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

Если используются торговые предложения, цена может относиться именно к предложению, а не к родительскому товару.

Поэтому фраза «цена в XML есть» ещё не означает, что она относится к тому объекту, который сейчас отображается на странице.

Диагностика строится по идентификатору конкретного товара или предложения.

↑ К оглавлению

8. Не обновляются остатки

С остатками ситуация похожая.

Сначала смотрим фактические данные CommerceML.

Если новое количество не передано, сайт не сможет его придумать.

В настройках обмена 1С могут участвовать:

• выбранные склады;
• общий остаток;
• остатки по магазинам;
• резерв.

Поэтому нужно заранее понимать, какой результат ожидается на сайте.

Например:

в 1С товар есть на складе №2, но этот склад не входит в текущую выгрузку

Тогда отсутствие соответствующего остатка на сайте может быть нормальным результатом выбранной настройки, а не ошибкой импорта.

Если остаток присутствует в XML, проверяем:

• идентификатор товара или предложения;
• склад;
• соответствие складов;
• результат импорта;
• пользовательский код после обновления.

↑ К оглавлению

9. Появляются дубли товаров и предложений

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

Иначе следующий обмен создаст их снова.

Одна из ключевых вещей при синхронизации — устойчивое соответствие идентификаторов между системами.

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

Проверяем:

• внешний идентификатор товара;
• внешний идентификатор предложения;
• изменения идентификаторов после переноса или копирования базы;
• несколько разных узлов обмена;
• несколько инфоблоков;
• пользовательский код импорта;
• ручное создание копий товаров.

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

Только затем безопасно исправлять существующие данные.

↑ К оглавлению

10. Не передаются заказы

Обмен заказами нужно диагностировать отдельно от каталога.

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

Сначала берём конкретный заказ.

Например:

Заказ №1234

и проверяем:

1. Он существует на сайте.
2. Его состояние позволяет участвовать в обмене.
3. Он попадает в данные, которые сайт отдаёт 1С.
4. 1С получает CommerceML.
5. В 1С заказ успешно разбирается.
6. Товары и покупатель сопоставляются корректно.

Поля заказа

Особое внимание требуется после изменения:

• свойств заказа;
• типов плательщика;
• способов оплаты;
• доставки;
• пользовательских полей;
• структуры документов.

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

Поэтому при проблемах с заказами нужно смотреть фактически переданный CommerceML конкретного заказа.

Не диагностировать всю систему по фразе «заказ не пришёл».

↑ К оглавлению

11. Обмен обрывается на больших файлах

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

Проверяем ограничения:

• PHP;
• веб-сервера;
• прокси;
• памяти;
• времени обработки;
• размера передаваемых частей;
• свободного места на диске.

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

Поэтому нельзя автоматически считать, что любая ошибка большой выгрузки решается увеличением одного PHP-параметра.

Нужно найти этап.

Обрыв при передаче

Проверяем:

• сеть;
• прокси;
• веб-сервер;
• ограничения размера запроса;
• место для временных файлов.

Обрыв при обработке

Проверяем:

• PHP error log;
• память;
• время выполнения;
• SQL;
• тяжёлые обработчики событий.

Если каждый повтор останавливается на одном и том же элементе, проблема может быть не в размере всего каталога, а в конкретных данных или пользовательском коде.

↑ К оглавлению

12. Проверяем серверные ошибки и пользовательский код

Обмен 1С запускает обычный серверный PHP-код 1С-Битрикс.

Поэтому на него способны влиять те же проблемы, что и на другие запросы:

• несовместимый PHP-код;
• ошибка после обновления;
• сторонний модуль;
• обработчик события;
• нехватка памяти;
• ошибка базы данных;
• закончившееся место;
• права на запись.

Если 1С сообщает:

«Произошла ошибка на стороне сервера»

этого недостаточно для диагноза.

Нужно взять точное время и посмотреть журнал PHP и веб-сервера.

Если там есть:

PHP Fatal error

или:

Allowed memory size exhausted

работаем уже с этой конкретной причиной.

Проверяем изменения проекта

Особенно внимательно смотрим код, добавленный перед появлением проблемы:

• /local/;
• init.php;
• обработчики инфоблоков;
• обработчики каталога;
• обработчики заказов;
• сторонние модули.

Пользовательский обработчик способен остановить добавление товара или изменить его данные уже после того, как CommerceML был успешно принят.

↑ К оглавлению

13. Полный и обмен изменениями

При нормальной работе постоянно отправлять весь каталог обычно не требуется.

Обмен может передавать только изменившиеся данные.

Из-за этого возникает типичная диагностическая ошибка:

настройку исправили → снова запустили обмен изменениями → товар не пришёл → решили, что исправление не помогло.

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

Поэтому при диагностике важно понимать текущий режим узла обмена.

Полная выгрузка иногда полезна как контролируемая проверка, но перед ней нужно оценить:

• размер каталога;
• время выполнения;
• нагрузку;
• существующие связи товаров;
• риск изменения рабочего каталога.

Не стоит использовать полную выгрузку как универсальную кнопку «починить синхронизацию».

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

↑ К оглавлению

14. Проверка после исправления

После изменения повторяем именно тот сценарий, который раньше завершался ошибкой.

Например:

до исправления

обмен товаров → авторизация PASS → файл PASS → импорт offers.xml → ошибка

После изменения проверяем:

обмен товаров → авторизация PASS → файл PASS → тот же этап импорта PASS → нужное предложение обновилось → цена обновилась → остаток обновился

Для заказа:

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

После этого проверяем ещё один обычный обмен.

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

Главный принцип:

воспроизвели → определили последний успешный этап → нашли фактическую ошибку → исправили → повторили тот же обмен

Так не приходится каждый раз заново перестраивать всю интеграцию.

↑ К оглавлению

15. Частые вопросы

Почему обмен 1С с Битрикс раньше работал, а потом перестал?

Сначала проверяем изменения между последним успешным и первым неуспешным обменом: обновление 1С, модуля обмена, ядра 1С-Битрикс, PHP, HTTPS, сервера, пароля пользователя или пользовательского кода. Затем определяем этап, на котором обмен сейчас останавливается.

Что делать при сообщении «Произошла ошибка на стороне сервера»?

Запишите точное время ошибки и проверьте журналы PHP и веб-сервера. Сообщение со стороны 1С слишком общее. В серверном журнале часто находится реальная причина: фатальная ошибка PHP, нехватка памяти, ошибка SQL или проблема прав.

Почему товары обновляются, а цены или остатки нет?

Товары, цены и остатки имеют отдельные настройки и данные обмена. Сначала откройте CommerceML и проверьте наличие нужной цены или остатка. Затем смотрите выбранные прайсы, склады и соответствие конкретного товара или предложения.

Нужно запускать полную выгрузку при любой ошибке?

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

Почему после обмена появляются дубли товаров?

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

В каком формате 1С-Битрикс обменивается данными с 1С?

Для стандартного обмена каталогом используется CommerceML v2 — XML-формат коммерческой информации. Через него передаются товары и связанные данные обмена. Конкретный состав зависит от настроек узла: товары, предложения, свойства, цены, остатки и другие данные.

Нужно исправить обмен 1С с 1С-Битрикс?

Проверю обмен по этапам: подключение, авторизацию, передачу CommerceML, импорт товаров и предложений, цены, остатки и заказы. Найду место, на котором синхронизация нарушается, исправлю причину и повторю обмен на том же сценарии.

Здесь, без регистрации

Через KWORK