Дубли товаров после обмена с 1С: что зафиксировать и как проверить исправление

Удаление требует карты связей

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

Разберём магазин на 1С-Битрикс. Товары и варианты поступают из 1С, а сайт использует эти записи в каталоге и заказах. Владельцу нужно понять связь объектов двух систем и подготовить приёмку, которую команда повторит после исправления обмена. Массовая чистка базы преждевременна: сначала сохраняют сведения и устанавливают, какие карточки описывают одну позицию, а какие относятся к разным исполнениям. В результате появляется перечень подтверждённых дублей с кодами и связанными заказами, по которому можно обсуждать судьбу каждой записи.

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

Товар узнают по идентификатору

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

У сайта несколько разных кодов. В описании полей инфоблока Битрикс ID обозначает внутренний идентификатор элемента, XML_ID — внешний код, CODE — символьный код. Эти значения решают разные задачи. Число в административной карточке не следует автоматически копировать в поле внешнего обмена. Сначала специалист показывает, какой признак передаёт 1С и с каким полем его сопоставляет сайт. Тогда изменение кода можно оценивать по последствиям.

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

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

Название и артикул решают другие задачи

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

Сходство требует расшифровки. Товарный специалист сравнивает производителя, исполнение, единицу продажи и состав поставки. Исполнитель обмена смотрит идентификаторы и источник записи. Маркетолог отмечает публичные адреса. Руководитель каталога решает, какие сведения считать основной карточкой после восстановления связи. Такое распределение снимает опасное ожидание, будто программная сортировка одинаковых названий уже подготовила список на удаление.

Объединять карточки по совпавшему артикулу хуже, чем сначала подтвердить товарную модель, потому что одна строка может описывать отдельную упаковку или исполнение, а потеря такого различия изменит выбор покупателя и состав будущего заказа. Для спорных записей сохраняют отдельный статус разбора. Их не включают в автоматическую очистку. Когда значение артикула действительно уникально в конкретном источнике, это правило явно фиксируют, а не предполагают по привычке.

Предложения отделяют от дублей

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

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

В курсе интеграции Битрикс с 1С описан обмен в формате CommerceML на основе XML и работа с каталогом и предложениями, поэтому специалист показывает, какие объекты содержала выгрузка и как они связались на принимающей стороне. Заказчику не требуется читать XML вручную. Ему нужна понятная схема модели и вариантов с фактическими кодами. По ней товарный специалист подтверждает состав предложения, а разработчик объясняет, где нарушилась связь. Исходные файлы обмена сохраняют в закрытом рабочем наборе для повторного испытания.

Результат товарной проверки — список подтверждённых дублей и отдельный список нормальных вариантов либо ошибок связи. Такое разделение экономит работу: исправление идентификации и восстановление структуры предложений могут потребовать разных действий.

Откуда приходит повторная запись

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

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

Типовой адрес обмена в документации Битрикс содержит путь /bitrix/admin/1c_exchange.php. Это конкретный ориентир для разговора с исполнителем, а не указание самостоятельно менять настройки работающего магазина. На доработанном сайте может использоваться другой обработчик. Специалист показывает фактический адрес и профиль, исключая пароли и другие секреты из отчёта. Так запись о «запуске обмена» связывается с определённым источником данных.

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

Восстановление связей без потери заказов

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

Сначала восстанавливают правило узнавания. Исполнитель объясняет, какой идентификатор будет сохраняться и где исправлено его соответствие. Затем команда определяет основную запись для каждой подтверждённой пары. Учитываются заказы, изображения, тексты, публичный адрес и другие связи. Похожая карточка с более свежей ценой не обязательно удобна как основная. Основной остаётся запись, для которой команда подготовила сохранение нужных данных и связей.

Массовое удаление без карты связей опасно: могут исчезнуть объекты, на которые уже ссылаются заказ, торговое предложение или рекламная ссылка, а компании придётся восстанавливать не только товар, но и смысл прежних операций. План исправления показывает судьбу каждой группы данных. До запуска специалист убеждается, что резервная копия позволяет вернуть затронутые записи и их связи. Для публичных адресов отдельно продумывают переход посетителей. Историю заказа после изменения открывают сотрудники, чтобы подтвердить сохранность состава покупки и сведений для дальнейшей работы.

Заказчику стоит запросить перечень операций в понятной форме: какие записи сохраняются, какие перестают показываться, какие сведения переносятся и как отменить изменение при расхождении. Детали команд остаются у специалиста. Принять можно план с известными объектами и способом восстановления, а не обещание «почистим базу заодно».

Повторная выгрузка подтверждает исправление

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

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

• У прежнего товара сохранены внутренний ID и ожидаемый внешний код.
• Цена и наличие относятся к нужному исполнению.
• Торговые предложения связаны с правильной моделью.
• Старые заказы читаются и содержат нужные позиции.
• Публичные ссылки ведут к доступному предложению.

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

Пакет сведений для двух специалистов

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

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