При настройке синхронизации между конфигурациями 1С:Управление торговлей 11 (УТ) и 1С:Бухгалтерия предприятия 3.0 (БП) через универсальный формат EnterpriseData часто возникает критическая проблема: справочник ДоговорыКонтрагентов начинает бесконтрольно размножаться. Ситуация выглядит следующим образом: при первоначальном обмене договор сопоставляется корректно, однако при передаче документов (заказов, реализаций, поступлений) в базе БП создаются новые дубликаты договора на каждый входящий документ.
В этой статье мы подробно разберем, почему механизм идентификации по GUID может давать сбой, как проанализировать содержимое XML-файла обмена и каким образом внести изменения в программный код менеджера обмена, чтобы остановить мультипликацию данных.
Для начала проанализируем, как работает поиск объектов в универсальном формате. В отличие от старых правил конвертации (КД 2.0), где поиск часто настраивался «галочками», обмен через EnterpriseData опирается на два эшелона идентификации:
СоответствияОбъектовИнформационныхБаз. Если запись найдена, объект сопоставляется мгновенно.GUID объект не найден (или он не передан), система обращается к правилам, описанным в общем модуле МенеджерОбменаЧерезУниверсальныйФормат, и пытается найти объект по комбинации реквизитов (например, ИНН/КПП для контрагента или Номер/Дата/Организация для договора).Выясним причину сбоя: почему при передаче документа в БП создается новый договор, даже если сам справочник ранее был успешно синхронизирован? Проблема часто кроется в том, что в XML-пакете обмена внутри узла документа информация о договоре передается не как полноценная ссылка с GUID, а как набор ключевых свойств. Если эти свойства (например, дата или номер) в УТ и БП хоть немного различаются, поиск по полям поиска не срабатывает, и система, следуя своей логике, создает новый объект.
Рассмотрим по шагам, как проверить, что именно передает УТ. Для этого необходимо выгрузить данные в файл и открыть его любым текстовым редактором или средством просмотра XML. Проанализируем раздел, отвечающий за документ (например, Документ.РеализацияТоваровУслуг). Найдем в нем тег, описывающий договор.
Если мы видим, что в блоке договора отсутствует тег Ссылка с уникальным идентификатором, а присутствуют только строковые значения реквизитов, это подтверждает догадку: УТ не передает GUID договора в составе документа. В этом случае БП вынуждена полагаться исключительно на алгоритмы поиска, прописанные в коде менеджера обмена.
Поскольку у нас нет возможности изменить правила через «Конвертацию данных» (если используются типовые правила, «зашитые» в код), нам придется работать с общим модулем МенеджерОбменаЧерезУниверсальныйФормат на стороне 1С:Бухгалтерии. Наша задача — переопределить приоритеты и состав полей поиска для справочника ДоговорыКонтрагентов.
Разберем пример модификации процедуры ДобавитьПКО_Справочник_ДоговорыКонтрагентов. В типовом коде поля поиска могут быть избыточными или, наоборот, недостаточными (например, поиск идет по номеру и дате, которые в УТ часто не заполнены в соглашениях).
Ниже представлен пример кода, который принудительно устанавливает вариант идентификации и расширяет список полей поиска, добавляя поиск по наименованию как «последний шанс» перед созданием дубля:
Процедура ДобавитьПКО_Справочник_ДоговорыКонтрагентов(ПравилаКонвертации)
ПравилоКонвертации = ОбменДаннымиXDTOСервер.ИнициализироватьПравилоКонвертацииОбъекта(ПравилаКонвертации);
ПравилоКонвертации.ИмяПКО = "Справочник_ДоговорыКонтрагентов";
ПравилоКонвертации.ОбъектДанных = Метаданные.Справочники.ДоговорыКонтрагентов;
ПравилоКонвертации.ОбъектФормата = "Справочник.Договоры";
ПравилоКонвертации.ПриКонвертацииДанныхXDTO = "ПКО_Справочник_ДоговорыКонтрагентов_ПриКонвертацииДанныхXDTO";
ПравилоКонвертации.ПередЗаписьюПолученныхДанных = "ПКО_Справочник_ДоговорыКонтрагентов_ПередЗаписьюПолученныхДанных";
ПравилоКонвертации.ПослеЗагрузкиВсехДанных = "ОтложеннаяОбработка_ДоговорыКонтрагентов";
// Устанавливаем приоритет поиска по уникальному идентификатору
ПравилоКонвертации.ВариантИдентификации = "СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска";
СвойстваШапки = ПравилоКонвертации.Свойства;
ДобавитьПКС(СвойстваШапки, "ВалютаВзаиморасчетов", "", 1);
ДобавитьПКС(СвойстваШапки, "ВидДоговора", "ВидДоговора", , "ВидыДоговоров");
ДобавитьПКС(СвойстваШапки, "Владелец", "Контрагент", , "Справочник_Контрагенты_Получение");
ДобавитьПКС(СвойстваШапки, "Дата", "Дата");
ДобавитьПКС(СвойстваШапки, "Наименование", "Наименование", 1);
ДобавитьПКС(СвойстваШапки, "Номер", "Номер");
ДобавитьПКС(СвойстваШапки, "Организация", "Организация", , "Справочник_Организации_Получение");
// Определяем стратегии поиска (порядок важен!)
// Стратегия 1: Поиск по полному совпадению ключевых реквизитов (Номер, Дата, Владелец)
ПравилоКонвертации.ПоляПоиска.Добавить("ВидДоговора,Владелец,Дата,Номер,Организация,ЭтоГруппа,ВалютаВзаиморасчетов");
// Стратегия 2: Поиск по наименованию и владельцу (если номер/дата не совпадают)
ПравилоКонвертации.ПоляПоиска.Добавить("ВалютаВзаиморасчетов,ВидДоговора,Владелец,Наименование,Организация,ЭтоГруппа");
// Стратегия 3: Упрощенный поиск (добавлено вручную для минимизации дублей)
ПравилоКонвертации.ПоляПоиска.Добавить("ВидДоговора,Владелец,Наименование,Организация");
КонецПроцедуры
Проанализируем внесенные изменения. Добавление строки ПравилоКонвертации.ПоляПоиска.Добавить("ВидДоговора,Владелец,Наименование,Организация"); позволяет системе найти уже существующий договор, даже если в XML не пришел его номер или дата. Однако стоит учитывать риск: если у одного контрагента по одной организации есть два договора с одинаковым наименованием (например, «Основной договор»), система привяжет документ к первому попавшемуся. Это все же лучше, чем создание десятков дублей, но требует аккуратности в ведении учета.
Также обратим внимание на владельца (контрагента). При поиске договора внутри документа критически важно, чтобы сам контрагент был успешно идентифицирован. Если в XML-файле данные контрагента переданы некорректно, поиск договора по владельцу не даст результатов, и система создаст новый договор с «пустым» или новым контрагентом.
Если программная корректировка полей поиска не помогает, рекомендуем проверить следующие моменты:
РегистрацияИзмененийДляОбмена, чтобы увидеть, какие объекты стоят в очереди на выгрузку.EnterpriseData (например, 1.10). В разных версиях состава формата Справочник.Договоры могут быть разные обязательные поля для поиска.Подведем итог. Чтобы остановить мультипликацию договоров, необходимо обеспечить либо передачу GUID (что требует правки правил выгрузки на стороне УТ), либо настроить надежный поиск по ключевым полям на стороне БП через модификацию МенеджерОбменаЧерезУниверсальныйФормат. Рассмотрим второй вариант как наиболее оперативный, так как он позволяет «подхватить» уже существующие в базе БП договоры по их наименованию и владельцу.