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