Как решить проблему задвоения контрагентов, номенклатуры и валюты при обмене УТ – БП?

← На главную

Синхронизация данных между конфигурациями 1С:Управление торговлей (УТ) и 1С:Бухгалтерия предприятия (БП) — это стандартная задача, с которой сталкивается практически каждый программист 1С. Однако на практике часто возникает крайне неприятная ситуация: после очередного сеанса интеграции в базе-приемнике (как правило, в БП) начинают лавинообразно плодиться дубликаты справочников. Задваиваются базовые валюты, контрагенты, договоры и позиции номенклатуры.

Обычные попытки исправить ситуацию «на лету» — например, отключить в правилах обмена поиск по уникальному идентификатору (УИД) и настроить сопоставление только по коду — зачастую не приносят желаемого результата. Давайте детально разберем причины этой проблемы, выясним, почему простой поиск по коду дает сбой, и рассмотрим пошаговый алгоритм полного исправления базы данных и настройки надежного обмена.

Почему отключение поиска по УИД и выбор сопоставления по «Коду» не работают?

Рассмотрим ситуацию, когда программист вносит изменения в правила конвертации объектов (ПКО) в программе Конвертация данных 2.1. Он снимает флаг «Искать объект приемника по внутреннему идентификатору источника» и устанавливает поиск исключительно по полю Код. На первый взгляд, это логично: если коды в УТ и БП совпадают, система должна найти существующий объект. Но на практике дубли все равно создаются. Выделим несколько скрытых причин, почему так происходит:

Разнородная длина кодов в конфигурациях. В базах УТ и БП длина кода для одного и того же справочника (например, номенклатуры или контрагентов) может различаться. Допустим, в УТ длина кода составляет 11 символов, а в БП — 9. При выгрузке код дополняется ведущими нулями или пробелами. Для платформы 1С строка "00-00000001" и строка "000000001" абсолютно не равны. Точный поиск по коду не находит совпадений, и система создает новый элемент.
Влияние подчиненных справочников (Владельцы). Справочник Договоры контрагентов жестко подчинен справочнику Контрагенты. Если сам контрагент из-за различий в идентификаторах или кодах создался как дубликат, то при поиске договора система будет искать его только внутри папки («владельца») этого нового, задублированного контрагента. Естественно, там договора с нужным кодом не окажется, и система создаст дубль договора.
Иерархия и родительские группы (Номенклатура). Если для номенклатуры включена опция «Искать в группе» (проверка по родителю), а структура папок в БП и УТ хотя бы немного различается (например, одна и та же папка в УТ лежит в корне, а в БП перенесена внутрь другой группы), то поиск по коду внутри конкретной группы вернет ложь. Результат — создание дубликата товара.
Генерация случайных УИД. При отключенном поиске по внутреннему идентификатору, если поиск по коду завершился неудачно, система создает новый элемент и присваивает ему абсолютно случайный УИД. В дальнейшем сопоставить эти объекты автоматически без ручного вмешательства становится невозможно.
Специфика справочника «Валюты». Валюты в системах 1С имеют предопределенные механизмы работы. Поиск валют часто завязан не на символьный код (например, "USD" или "RUB"), а на цифровой код классификатора (840 или 643). Если правила поиска в КД настроены неверно, сопоставление по строковому коду просто игнорируется, порождая дубли рублей или долларов, на которые сразу же вешаются проводки документов.

Шаг 1. Наведение порядка и слияние дублей в базе данных

Если обмен уже отработал некорректно и в базе БП появились дубликаты, простое изменение правил обмена не поможет. Новые документы будут продолжать ссылаться на новые «неправильные» элементы, а на «правильных» останутся старые обороты. Нам необходимо выполнить процедуру очистки.

Для этого воспользуемся стандартной обработкой «Поиск и удаление дублей», которая доступна в разделе «Администрирование» — «Обслуживание» (или на ИТС). Выполняем следующие действия:

Выбираем область поиска (например, справочник Контрагенты или Номенклатура).
Задаем правила сравнения (например, совпадение по ИНН и КПП для контрагентов или по Наименованию для номенклатуры).
Запускаем поиск. В списке найденных дублей внимательно анализируем, какой объект сделать «Оригиналом» (обычно это тот, у которого наиболее полно заполнены реквизиты или на который завязано больше старых документов), а какие пометить как «Дубли».
Нажимаем кнопку «Удалить дубли». При этом обработка автоматически найдет все ссылки на дубли во всех документах, регистрах сведений и накопления, заменит их ссылками на выбранный оригинал, а сами дубли пометит на удаление.

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

Шаг 2. Выравнивание уникальных идентификаторов (GUID)

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

Проанализируем техническое решение этой задачи. Мы можем использовать внешнюю обработку для перезаписи УИД в базе БП, чтобы они стали равны идентификаторам из УТ. Ниже представлен пример кода, демонстрирующий логику сопоставления объектов по ключевому реквизиту (например, ИНН для контрагентов) и принудительной синхронизации их GUID через создание нового объекта с заданным УИД взамен старого:


// Пример переноса УИД контрагента для предотвращения дублирования
Процедура СинхронизироватьУИДКонтрагента(СсылкаНаПриемник, СтрокаУИДИсточника)
    
    НовыйУИД = Новый УникальныйИдентификатор(СтрокаУИДИсточника);
    
    // Проверяем, существует ли уже объект с таким УИД в приемнике
    НайденныйОбъект = Справочники.Контрагенты.ПолучитьСсылку(НовыйУИД);
    
    Если НайденныйОбъект.ПолучитьОбъект() = Неопределено Тогда
        // Создаем новый элемент с УИД источника, копируя данные старого элемента
        НовыйОбъект = Справочники.Контрагенты.СоздатьЭлемент();
        НовыйОбъект.УстановитьСсылкуНового(НайденныйОбъект);
        
        ЗаполнитьЗначенияСвойств(НовыйОбъект, СсылкаНаПриемник.ПолучитьОбъект(), "Код,Наименование,ИНН,КПП,ЮридическийАдрес");
        НовыйОбъект.Записать();
        
        // Заменяем ссылки в транзакциях со старого элемента на новый с правильным УИД
        СсылкаНаПриемник.ПолучитьОбъект().УстановитьПометкуУдаления(Истина);
        ИнформационнаяБаза.ЗаменитьСсылки(СсылкаНаПриемник, НайденныйОбъект);
    КонецЕсли;

КонецПроцедуры

Шаг 3. Использование обработчика «Поля поиска» в Конвертации Данных

Если мы хотим оставить обмен через XML-файлы, но научить систему корректно сопоставлять контрагентов без жесткой привязки к УИД (например, по связке ИНН + КПП), мы должны использовать обработчики событий в КД 2.1.

Рассмотрим, как настроить сопоставление в ПКО контрагентов. В обработчике события ПоляПоиска напишем следующий алгоритм:


// Алгоритм сопоставления контрагентов по ИНН и КПП при поиске
Если СвойстваПоиска.Свойство("ИНН") И ЗначениеЗаполнено(СвойстваПоиска["ИНН"]) Тогда
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	Контрагенты.Ссылка КАК Ссылка
        |ИЗ
        |	Справочник.Контрагенты КАК Контрагенты
        |ГДЕ
        |	Контрагенты.ИНН = &ИНН
        |	И Контрагенты.КПП = &КПП
        |	И НЕ Контрагенты.ПометкаУдаления";
        
    Запрос.УстановитьПараметр("ИНН", СвойстваПоиска["ИНН"]);
    Запрос.УстановитьПараметр("КПП", СвойстваПоиска["КПП"]);
    
    РезультатЗапроса = Запрос.Выполнить();
    Если НЕ РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        СсылкаНайдена = Выборка.Ссылка;
        ПрекратитьПоиск = Истина; // Прерываем стандартный поиск по УИД/коду
    КонецЕсли;
    
КонецЕсли;

Использование этого кода гарантирует, что система сначала попытается найти контрагента по ИНН/КПП, и только если такой не будет найден, создаст нового с УИД базы-источника.

Шаг 4. Кардинальное решение — переход на Планы обмена

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

Современным и наиболее надежным решением является переход на типовой механизм синхронизации данных, использующий Планы обмена на базе БСП (Библиотеки Стандартных Подсистем). Разберем по шагам преимущества этого подхода:

Таблица сопоставления при первом запуске. При первичной настройке обмена через встроенный помощник система выгружает данные и перед их записью предлагает пользователю удобную форму интерактивного сопоставления. Вы можете вручную указать, какому контрагенту или валюте в БП соответствует объект из УТ, даже если у них абсолютно разные коды, ИНН или наименования.
Регистр соответствий объектов. Результат интерактивного сопоставления записывается в специальный регистр сведений СоответствияОбъектовИнформационныхБаз (в некоторых версиях — ПубличныеИдентификаторыСинхронизируемыхОбъектов). В этом регистре жестко фиксируется связь: УИД Источника <-> УИД Приемника.
Независимость от изменений в базах. После того как связь записана в регистр соответствий, бухгалтер в БП может переименовать контрагента, изменить код номенклатуры, перенести договор в другую группу — при последующих обменах дублирование не произойдет, потому что система сопоставит объекты по записи в регистре, полностью игнорируя изменившиеся реквизиты.

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