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