Why 1C Exchange Creates Product Duplicates: How to Find and Fix the Cause

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

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

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

Сделайте резервную копию базы данных и файлов, зафиксируйте время последнего успешного обмена и сохраните журналы. Выберите несколько пар «оригинал — дубль» из разных разделов. Для каждой пары запишите внутренний 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, gets lost, or is matched at the wrong level, the system treats the record as new.

Before diagnosing, pause the automatic exchange or switch it to a test circuit. Do not mass-delete products or run a full export to "fix" it: this can increase the number of copies and complicate restoring links.

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, catalogs were merged, or export rules changed, it may receive a new identifier.

The website retains the old card, while the new key creates another one. Compare the external codes of the original and duplicate with the identifier of the same item in 1C. If they differ, you must 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 as a catalog element with associated trade offers. In 1C, a similar structure is built from items and characteristics.

If the export configuration previously exported characteristics as offers but now creates separate products after configuration changes, the catalog will visually duplicate. The reverse can also occur: an item identifier is recorded instead of a characteristic identifier, causing different variants to compete for the same link.

Check the parent product key and the key for each offer separately. Do not merge them just 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 risky: identical models can come from different suppliers, and even a minor text change can break the link.

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

Compare the package that caused the duplicate with the previous successful one: export type, format version, identifiers, group structure, and offer structure. 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 recorded but before receipt is confirmed. 1C resends the packet, and the site handler creates the object again. A correct import must be idempotent: repeating an operation leads to the same state, not a new entity.

Check whether the packet 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 offers, images, stock levels, reviews, and SEO fields are moved.

The card to keep is chosen not just by date. An older page may have a search address, 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, 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 remapped 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 test product, then repeat the same package, and only then execute the full exchange. Compare the number of items and offers before and after each step.

A stable process includes several rules:

The main criterion for a successful fix is the absence of disappearing visible copies. You must prove that the same object maintains its link during changes, full exchanges, and re-uploads. Only then can the catalog be considered restored.