Почему обмен с 1С создаёт дубли товаров: как найти и устранить причину

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

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

Перед диагностикой приостановите автоматический обмен или переключите его на тестовый контур. Не удаляйте массово товары и не запускайте полную выгрузку «для исправления»: она может увеличить количество копий и усложнить восстановление связей.

Сделайте резервную копию базы данных и файлов, зафиксируйте время последнего успешного обмена и сохраните журналы. Выберите несколько пар «оригинал — дубль» из разных разделов. Для каждой пары запишите внутренний ID сайта, внешний идентификатор, артикул, тип сущности, дату создания и идентификаторы в 1С.

Этого небольшого набора обычно достаточно, чтобы увидеть общий рисунок.

Артикул и название видны пользователю, но интеграция часто связывает объект по GUID или другому внешнему коду. Если в 1С товар пересоздали, перенесли между базами, объединили справочники или изменили правила выгрузки, он может получить новый идентификатор.

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

В «1С-Битрикс: Управление сайтом» товар с цветами и размерами часто представлен элементом каталога и связанными торговыми предложениями. В 1С аналогичная структура строится из номенклатуры и характеристик.

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

Проверьте отдельно ключ родительского товара и ключ каждого предложения. Их нельзя объединять только потому, что совпадает артикул или часть названия.

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

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

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

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

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

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

Сначала устраните причину создания новых копий. Затем составьте таблицу объединения: какая карточка остаётся, какой внешний идентификатор закрепляется, куда переносятся предложения, изображения, остатки, отзывы и SEO-поля.

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

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

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

Устойчивый процесс включает несколько правил:

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

After another exchange, a second product with a similar name appears in the catalog. Sometimes only one size is duplicated, sometimes an entire group. Deleting the extra card seems like a quick fix, but it returns with the next export.

The cause is almost never in the name, but in the object links. Integration must recognize an existing product by a permanent identifier. If this key changes, is lost, or is matched at the wrong level, the system treats the record as new.

Before diagnostics, pause automatic exchange or switch it to a test circuit. Do not mass-delete products or run a full export to fix the issue: it may increase the number of copies and complicate link restoration.

Create a backup of the database and files, record the time of the last successful exchange, and save the logs. Select several original-duplicate pairs from different sections. For each pair, record the site internal ID, external identifier, SKU, entity type, creation date, and 1C identifiers.

This small set is usually sufficient to see the overall picture.

The SKU and name are visible to the user, but integration often links objects by GUID or another external code. If an item in 1C was recreated, moved between databases, dictionaries were merged, or export rules changed, it may receive a new identifier.

The old card remains on the site, while the new key creates another one. Compare the external codes of the original and the duplicate with the identifier of the same nomenclature in 1C. If they differ, restore the correspondence using the approved table, not by matching names.

In 1C-Bitrix: Site Management, a product with colors and sizes is often represented by a catalog element and linked product variants. In 1C, a similar structure is built from nomenclature and characteristics.

If the export configuration previously exported characteristics as variants but, after configuration changes, began creating separate items, the catalog will visually duplicate. The opposite case is also possible: the nomenclature identifier is recorded instead of the characteristic identifier, so different variants compete for the same link.

Check the parent item key and the key of each variant separately. They must not be merged simply because the SKU or part of the name matches.

Manually creating a product on the website is not always compatible with subsequent automatic export. A manager might have added a card without an external identifier, while 1C later created its own version. The same issue occurs after importing a catalog from a table if the import does not preserve the accounting system keys.

You must define a single source for the catalog structure or describe a procedure for linking manual cards. Automatic matching by name is dangerous: identical models can come from different suppliers, and a minor text change can break the link.

A standard exchange may transmit only changes, while a manual full export uses a different set of fields or a different schema version. After updating the module, 1C configuration, or modifying the data path handler, discrepancies sometimes arise.

Compare the package that caused the duplicate with the previous successful one: export type, format version, identifiers, group structure, and product variants. It is crucial to identify the exact moment the duplicate appeared, rather than analyzing the last run, which might have only updated an already existing copy.

A network failure can occur after a product is written but before acceptance is confirmed. 1C repeats the package, and the site handler creates the object again. Proper import must be idempotent: repeating an operation leads to the same state, not a new entity.

Check whether the package identifier is stored, if it can be retried after a timeout, and if an existing object is searched for before creation. Pay special attention to custom handlers, queues, and intermediate services.

First, eliminate the cause of new copies being created. Then compile a merge table: which card remains, which external identifier is locked, and where product variants, images, stock levels, reviews, and SEO fields are moved.

The card to keep is chosen not only by date. An older page may have a search ranking, view history, and reviews, while a newer one may have the correct link to 1C. Sometimes it is safer to move the external identifier to the old card; other times, it is better to keep the new one and set up a redirect from the old address. The decision depends on the data and catalog architecture.

Orders cannot be re-linked blindly. Old order lines must preserve product history, price, and tax. Before a mass operation, verify a database copy and several orders from different periods.

After merging, first perform a small export of a single control product, then repeat the same package, and only then proceed with the full exchange. Compare the number of elements and product variants before and after each step.

A stable process includes several rules:

The disappearance of visible duplicates is not enough to consider the issue resolved. You must prove that the same object maintains its link during updates, full exchanges, and re-imports. Only then can the catalog be considered restored.