Диагностика и устранение ошибок обмена 1С и 1С-Битрикс
Обмен сломался — товары не обновляются, заказы не попадают в 1С. Стандартная ситуация для любого магазина, работающего дольше полугода. Проблема в том, что сообщения об ошибках в CommerceML-обмене нечёткие, а причин может быть десятки. Ниже — систематический подход к диагностике.
Первая точка диагностики: лог обмена в Битрикс
Магазин → Журнал обмена с 1С — первое место для проверки:
- Зелёная строка — обмен прошёл успешно
- Красная строка — ошибка, раскрыть для деталей
- Отсутствие записей — обмен не запускался (проблема в расписании или авторизации)
Типичные сообщения и их значение:
| Сообщение | Причина |
|---|---|
Неверный логин или пароль |
Пользователь обмена заблокирован или сменился пароль |
Неверный ответ сервера |
HTTP 500 на 1c_exchange.php, смотреть PHP error_log |
Не найдено свойство PROP_XXX |
Свойство удалено на сайте, но 1С всё ещё его передаёт |
Превышен лимит времени |
Таймаут PHP при разборе большого XML |
Ошибка разбора XML |
Повреждённый файл или неправильная кодировка |
Диагностика через прямой запрос
Проверить работу endpoint вручную через curl или Postman:
# Шаг 1: авторизация
curl -c cookies.txt \
"https://myshop.ru/bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth" \
-u "login:password"
# Шаг 2: инициализация
curl -b cookies.txt \
"https://myshop.ru/bitrix/admin/1c_exchange.php?type=catalog&mode=init"
Ответ success на первый запрос — авторизация работает. Ответ failure — проверить права пользователя и статус учётной записи.
Ошибки типа «товары задвоились»
Самая неприятная ситуация: после обмена количество товаров в инфоблоке удвоилось. Причина — изменились GUID-идентификаторы товаров в 1С (перенос базы, реструктуризация), Битрикс не нашёл существующие элементы по ID и создал новые.
Диагностика:
SELECT XML_ID, COUNT(*) as cnt
FROM b_iblock_element
WHERE IBLOCK_ID = :iblock_id
GROUP BY XML_ID
HAVING cnt > 1;
Дубли: записи с одинаковым XML_ID или похожим артикулом, разным ID.
Устранение:
- Найти соответствие старых и новых GUID через артикул или штрих-код
- Обновить
XML_IDу существующих элементов на новые GUID из 1С - Деактивировать (не удалять) дубли
- Запустить обмен повторно — теперь 1С найдёт элементы по корректному XML_ID
Ошибки при обмене заказами
Заказы не попадают в 1С. Проверить:
- В настройках обмена на сайте включена опция «Выгружать заказы»
- Статус заказа включён в список статусов для выгрузки
- Пользователь обмена имеет доступ к
saleмодулю
1С создаёт заказы с «неизвестной номенклатурой». Товар в заказе не имеет свойства CML2_LINK с GUID из 1С. Такое бывает для товаров, созданных вручную на сайте. Решение — вручную заполнить CML2_LINK или исключить такие товары из передачи в 1С.
Проблемы с кодировкой
1С в старых конфигурациях может выгружать Windows-1251. Признак — кракозябры в названиях товаров после импорта.
// В обработчике события перед импортом
if (!mb_detect_encoding($xmlContent, 'UTF-8', true)) {
$xmlContent = mb_convert_encoding($xmlContent, 'UTF-8', 'Windows-1251');
}
В новых версиях УТ проблема устранена — выгрузка всегда в UTF-8.
Кейс: «пропавшие» товары после плановых работ
Хостинг-провайдер перенёс базу данных на новый сервер с другой версией MySQL. После переноса — обмен прошёл, но 12% товаров «исчезли» с сайта (статус ACTIVE = N). Причина: при переносе несколько тысяч значений XML_ID получили лишние пробелы из-за разницы в обработке CHAR и VARCHAR полей. Битрикс не нашёл элементы по XML_ID с пробелом — создал новые, старые деактивировал.
Диагностика показала проблему за 15 минут (SELECT * FROM b_iblock_element WHERE XML_ID LIKE '% %'). Исправление: UPDATE b_iblock_element SET XML_ID = TRIM(XML_ID) — и повторный запуск обмена восстановил все товары.
Превентивный мониторинг
Настроить автоматическую проверку после каждого обмена:
// Подозрительные признаки — сигнал для уведомления
$checks = [
'deactivated_count' => 'SELECT COUNT(*) FROM b_iblock_element WHERE ACTIVE = "N" AND MODIFIED_BY = 1', // изменено агентом обмена
'duplicate_xml_id' => 'SELECT COUNT(*) FROM (SELECT XML_ID FROM b_iblock_element GROUP BY XML_ID HAVING COUNT(*) > 1) t',
'last_exchange' => 'SELECT MAX(TIMESTAMP_X) FROM b_iblock_element WHERE IBLOCK_ID = ' . CATALOG_IBLOCK_ID,
];
Если количество деактивированных товаров за одну сессию обмена превышает порог (например, 100 штук) — отправить алерт и заблокировать следующий сеанс обмена до ручной проверки.
Сроки диагностики и устранения
| Тип проблемы | Срок устранения |
|---|---|
| Ошибка авторизации / таймаут | 1–2 часа |
| Задвоение товаров | 4–8 часов |
| Несоответствие кодировок | 1–3 часа |
| Потеря заказов при обмене | 2–4 часа |
| Системные проблемы после переноса БД | 1–2 дня |







