Діагностика та виправлення помилок обміну 1С і Бітрікс

Інтеграція 1С і Бітрікс — процес стабільний, доки не трапляється збій. Товари перестають оновлюватися, замовлення не доходять до облікової системи, а в логах — Неверный ответ сервера або Превышен лимит времени. Найчастіше проблема криється в авторизації користувача обміну, пошкодженому XML-файлі або невідповідності GUID. Ми — команда інженерів Бітрікс — щодня усуваємо помилки обміну 1С і Бітрікс. Наш досвід: 80% проблем вирішуються за 2 години, складні — за 1–2 дні. Оцінимо ваш проект, запропонуємо план, дамо гарантію. Нижче — перевірена методика діагностики, яка допомагає виявити причину за 15 хвилин.

Типові помилки: задвоєння товарів (дублі XML_ID), втрата замовлень (невірні статуси або відсутність CML2_LINK), кракозябри (кодування Windows-1251). Розкажемо, як їх діагностувати та усунути. У цій статті — конкретні SQL-запити, curl-команди та PHP-код для превентивного моніторингу.

Наша методика діагностики в 3 рази швидше стандартного аналізу логів — замість перебору всіх записів ми використовуємо паттерн-матчинг за типовими помилками. Економія часу після налаштування моніторингу — до 30%.

Як читати лог обміну в Бітрікс?

Магазин → Журнал обмена с 1С — перше місце для перевірки:

• Зелений рядок — обмін пройшов успішно
• Червоний рядок — помилка, розкрити для деталей
• Відсутність записів — обмін не запускався (проблема в розкладі або авторизації)

Типові повідомлення та їх значення:

1С-Бітрікс документація: CommerceML

Діагностика через прямий запит

Перевірити роботу 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. Усунення:

1. Знайти відповідність старих і нових GUID через артикул або штрих-код
2. Оновити XML_ID у існуючих елементів на нові GUID з 1С
3. Деактивувати (не видаляти) дублі
4. Запустити обмін повторно — тепер 1С знайде елементи за коректним XML_ID

Чому замовлення не потрапляють в 1С?

Перевірити:

1. В налаштуваннях обміну на сайті включена опція «Вивантажувати замовлення»
2. Статус замовлення включений в список статусів для вивантаження
3. Користувач обміну має доступ до sale модуля

1С створює замовлення з «невідомою номенклатурою» — товар в замовленні не має властивості CML2_LINK з GUID з 1С. Рішення: вручну заповнити CML2_LINK або виключити такі товари з передачі.

Проблеми з кодуванням

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) — і повторний запуск обміну відновив всі товари.

Що входить в роботу

• Аудит логів обміну та конфігурацій
• Фікс виявлених помилок (авторизація, дублі, кодування)
• Налаштування превентивного моніторингу
• Консультація з оптимізації обміну
• Гарантія на результат — 30 днів

Як налаштувати превентивний моніторинг?

Автоматична перевірка після кожного обміну:

// Підозрілі ознаки — сигнал для сповіщення $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 день. Сертифіковані спеціалісти 1С-Бітрікс, 5+ років досвіду, понад 100 проектів. Отримайте консультацію інженера — це безкоштовно.