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

Сначала нарисуйте поток данных

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

1С → CommerceML → модуль обмена → инфоблок → каталог
сайт → заказ → CommerceML → 1С → статус → сайт

Отдельно опишите идентификаторы: XML_ID товара, предложения, характеристики, склада и типа цены. Именно они связывают повторные выгрузки с уже созданными объектами.

Семь типовых причин

  1. изменились внешние идентификаторы и появились дубли;
  2. товар и торговое предложение сопоставлены неверно;
  3. тип цены или склад не привязан к сайту;
  4. файл превышает лимиты PHP или веб‑сервера;
  5. шаг импорта не укладывается во время выполнения;
  6. кастомный обработчик изменяет данные после импорта;
  7. полный обмен запускается в часы пик и перегружает базу.

Как диагностировать без повторных запусков вслепую

  • сохраните проблемный пакет CommerceML;
  • зафиксируйте время и тип обмена;
  • проверьте журнал 1С и серверные логи;
  • найдите один товар по внешнему идентификатору на всех этапах;
  • сравните входное значение с данными инфоблока и каталога;
  • временно отключайте только подтверждённые обработчики;
  • повторяйте тест на копии или ограниченном наборе.
DATA CONTRACTСтабильный обмен начинается с договора о владельце каждого поля и неизменяемых идентификаторах.

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