Если после обмена с 1С в Битрикс появились одинаковые товары, сначала проверьте, сохраняется ли соответствие внешнего идентификатора одной и той же записи на сайте. Одинаковое название ещё не доказывает дубль: это могут быть разные характеристики или повтор одного элемента на витрине. Удаление «лишней» карточки до проверки связей с заказами может усложнить восстановление.
Три безопасных первых действия:
- Зафиксируйте время проблемного обмена и внутренние ID двух похожих карточек в административной части.
- Сравните их внешние коды, инфоблоки и характеристики, ничего не сохраняя.
- Сохраните исходные пакеты обмена в закрытом рабочем контуре и проверьте наличие резервной копии базы и файлов.
Сначала отделите дубль записи от повторного показа
Этот разбор нужен руководителю интернет-магазина на «1С-Битрикс: Управление сайтом», которому требуется поставить разработчику проверяемую задачу. Он относится к обмену каталогом с 1С; инструкции для CRM Битрикс24 здесь не применяются автоматически.
Если в двух местах витрины показан один внутренний ID, проверяют вывод каталога, разделы и кеш. Это ещё не создание второй записи. Если ID разные, сравнивают тип сущности: основной товар и его торговое предложение — отдельные объекты. Предложение описывает конкретное сочетание характеристик, например размер и цвет.
Дубль становится рабочей гипотезой, когда разные ID обозначают одну и ту же учётную позицию с одинаковой характеристикой. Бизнес-риски здесь конкретны: покупатель выбирает устаревшую карточку, а цена или остаток обновляются у другой. Наличие двух похожих названий само по себе таких последствий не доказывает.
Соберите соответствия для двух обменов
В документации Битрикс поля разделены: ID — внутренний номер элемента, XML_ID — внешний идентификатор, IBLOCK_ID — номер инфоблока. Ни название, ни символьный код страницы не заменяют проверку внешней идентичности.
GUID — уникальный идентификатор объекта в исходной системе. Зафиксируйте его и фактический идентификатор, передаваемый модулем обмена. Для товара и характеристики они могут формироваться по-разному: нельзя заранее считать их одной строкой или самостоятельно обрезать составной код.
Ниже учебный пример, а не данные магазина. G-Т и G-П — условные обозначения GUID товара и предложения; это не значения для загрузки. Все строки относятся к заранее установленным целевым инфоблокам.
| Обмен / объект | GUID в 1С | XML_ID на сайте | ID на сайте |
|---|---|---|---|
| 1 / товар | G-Т | G-Т | 501 |
| 2 / тот же товар | G-Т | G-Т | 501 |
| 1 / предложение | G-П | G-П | 801 |
| 2 / то же предложение | G-П | G-П-v2 | 802 |
Товар сохранил ID, а у предложения изменилась пара «внешний код — запись сайта». Это повод найти место преобразования, а не доказательство вины конкретного модуля. Сравните идентификатор в исходном пакете, значение перед записью и сохранённый результат. Если пакет уже содержит новый код, проверка начинается на стороне выгрузки.
В рабочей таблице дополнительно нужны время сеанса, целевой инфоблок, связь предложения с товаром и наличие старой записи после второго обмена. Уточните, действительно ли обе строки относятся к одному объекту 1С. Реальные идентификаторы и пакеты храните у ответственных за проект; во внешнее обращение передавайте обезличенный пример.
Четыре гипотезы и признаки, которые их различают
Изменился идентификатор в исходной выгрузке
После переноса базы, пересоздания номенклатуры или изменения преобразования старый и новый пакеты могут содержать разные идентификаторы позиции. Проверяемый признак — различие видно ещё до импорта на сайт. Разработчик 1С должен установить, это прежний объект с изменённым соответствием или действительно новая номенклатура; сходства артикула недостаточно.
Данные попали в другой каталог
В официальной инструкции идентификатор каталога связывает выгрузку с конкретным инфоблоком. Поэтому сравнивают не только код товара, но и получателя обоих сеансов. Признак этой гипотезы — похожие записи оказались в разных инфоблоках либо изменилось соответствие каталога. Подмена кодов сразу у всего каталога не является диагностикой.
Перепутаны товар и предложение
У основного товара сохранился ID, а новые записи появляются только у размеров, цветов или других характеристик. Сравните полные внешние идентификаторы предложений и их связь с родительским товаром. Если две строки обозначают разные характеристики, объединять их нельзя, даже когда название совпадает.
Вторая запись создаётся внутри импорта
Входной идентификатор и целевой инфоблок не изменились, но возник новый внутренний ID. На копии разработчик проверяет поиск существующего элемента, пользовательские обработчики и возможные одновременные запуски импорта. Метод CIBlockElement::Add создаёт элемент, а его обработчики могут изменить поля: сам вызов добавления не подтверждает правильность предварительного сопоставления.
Признак для проверки — путь от одного входного объекта к двум сохранённым записям. Он требует разбора конкретного кода и журналов. По одному сообщению «обмен завершён» нельзя заключить, что повторный импорт безопасен.
Исправление проверяют на изолированной копии
Ответственный разработчик подготавливает копию с теми же версиями модулей и правилами обмена. У неё не должно быть действующих отправок покупателям, платежей или подключения к рабочей базе 1С. Для испытания используют согласованный тестовый источник или ограниченный пакет.
Сначала сохраняют исходную таблицу соответствий и воспроизводят симптом на контрольной позиции. Затем меняют только подтверждённую причину: правило сопоставления, выбор каталога, обработку характеристики или ветку создания элемента. Названия настроек и способ исправления зависят от конфигурации 1С и версии модуля — универсальной команды для всех магазинов нет.
Не удаляйте дубли и не переписывайте массово
XML_ID, пока не проверены ссылки заказов, корзин, резервов и внешних систем. Резервная копия должна восстанавливаться; наличие архива без пробного восстановления недостаточно.
Очистку накопленных дублей планируют отдельно от устранения причины. Для каждой пары выбирают сохраняемую запись и проверяют зависимые данные. Откат всей старой базы на работающий магазин может потерять новые заказы, поэтому план возврата должен учитывать изменения, поступившие после копирования.
Как принять исправление
Условие приёмки — стабильное соответствие одной учётной позиции одной нужной записи, а не просто уменьшение количества карточек. На тестовой копии проверьте:
- повторную обработку одного и того же контрольного пакета: новые ID не появляются;
- следующий обмен с согласованным изменением контрольного значения: обновляется прежняя запись;
- простой товар и товар с несколькими характеристиками: предложения остаются связаны с правильным родителем;
- старые заказы, корзины и резервы в проверяемом наборе: ссылки и состав не повреждены;
- незатронутую позицию: её данные не изменились из-за исправления.
После согласованного переноса исправления в рабочий проект наблюдают следующие штатные обмены и сравнивают ту же таблицу. Не создавайте реальные оплаты или заказы покупателей ради теста. Критерий остановки заранее: новый ID вместо ожидаемого либо нарушение зависимой записи требует приостановить дальнейшее изменение каталога и вернуться к диагностике.
Если ID стабильны, а расходятся только значения, полезен отдельный разбор: почему не приходят цены и остатки из 1С.
Когда достаточно своей команды, а когда нужна помощь
Своими силами можно собрать время обменов, версии, ID и внешние коды, сравнить карточки и передать таблицу штатному разработчику. Если он воспроизводит причину на копии и показывает выполнение критериев приёмки, привлекать другого подрядчика необязательно.
Когда соответствия меняет неизвестная доработка, нет безопасного стенда или затронуты заказы, требуется разбор интеграции. OpenStart принимает задачи по исправлению ошибок и доработке действующих сайтов; на странице доработки сайта можно описать такой сценарий для оценки. Для первого обсуждения достаточно симптома, времени обмена, версий и обезличенной пары записей. Пароли, полные выгрузки и данные покупателей в публичную форму не передают.