При переносе данных между базами 1С, особенно при загрузке остатков, часто возникает задача привязать документы к уже существующим объектам в базе-приемнике. Одной из наиболее специфичных задач является синхронизация справочника ДоговорыКонтрагентов. Проблема заключается в том, что в разных базах коды и наименования договоров могут не совпадать, а поиск по УникальномуИдентификатору (GUID) невозможен, если базы не являются идентичными копиями. В такой ситуации логичным кажется поиск «любого подходящего» договора по его владельцу — контрагенту.
В этой статье мы подробно разберем, как правильно настроить правила конвертации объектов (ПКО) для поиска только по владельцу, какие дополнительные реквизиты стоит включить в поиск для безопасности учета и как влияют настройки сессии обмена на итоговый результат.
Для начала проанализируем, как работает стандартный механизм поиска КД 2.0. Когда система встречает объект, для которого настроен поиск по полям, она формирует запрос к базе-приемнику. Если мы укажем в качестве поля поиска только Владелец, система попытается найти в справочнике Договоры записи, у которых поле Владелец совпадает со ссылкой на контрагента, уже найденного или созданного в текущей сессии.
Важный нюанс: если у одного контрагента в базе-приемнике заведено несколько договоров, платформа выберет первый попавшийся объект из выборки. Порядок этой выборки на уровне СУБД (SQL) без явной сортировки не гарантирован. Это означает, что при разных загрузках система теоретически может подставить разные договоры, если не принять дополнительных мер.
Рассмотрим по шагам, как настроить правила, чтобы поиск шел по владельцу, и при этом не создавались дубли:
Договоры.Владелец и установим для него галочку в колонке Поиск.Код или Наименование) в условия поиска автоматически, убедимся, что у этих реквизитов галочка Поиск снята.Однако, как показывает практика и обсуждение специалистов, поиска только по владельцу в 99% случаев недостаточно. Рассмотрим ситуацию: у контрагента есть договор с поставщиком и договор с покупателем. Если мы переносим остатки по закупкам и система «случайно» выберет договор с видом «С покупателем», проведение документа в базе-приемнике (например, в 1С:Бухгалтерии) завершится ошибкой или приведет к некорректным проводкам.
Чтобы избежать ошибок в учете, проанализируем необходимость добавления дополнительных критериев. Рекомендуется включать в поиск следующие реквизиты:
В настройках ПКО для этих реквизитов также следует установить флаг Поиск. В этом случае система найдет договор, который соответствует всем указанным параметрам, что значительно снижает риск «промаха».
Разберем технический момент, упомянутый в ходе обсуждения проблемы. В настройках правил выгрузки (или в самих правилах) существует опция Не запоминать выгруженные объекты. Посмотрим, как она влияет на наш случай:
Когда этот флаг снят (поведение по умолчанию), КД ведет внутреннюю таблицу соответствий (суррогатных ключей) в рамках одной сессии обмена. Если в файле выгрузки один и тот же договор встречается 10 раз в разных документах, система выполнит поиск в базе-приемнике только один раз (при первой встрече). Найденная ссылка сохранится в памяти, и для всех последующих документов будет использована она же. Это гарантирует единообразие данных в пределах одного обмена.
Если же флаг установлен, система будет выполнять запрос к базе данных приемника каждый раз. Это не только замедляет процесс, но и повышает риск того, что при наличии дублей в приемнике будут выбраны разные ссылки для одних и тех же данных в источнике.
Бывают ситуации, когда стандартных галочек недостаточно (например, нужно выбрать «основной» договор или договор с максимальной датой). В таких случаях мы используем обработчик Поля поиска в ПКО. Проанализируем пример кода, который можно там разместить:
// Пример кода в обработчике "Поля поиска"
Если НомерВариантаПоиска = 1 Тогда
// Пытаемся найти договор по владельцу и организации программно
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ДоговорыКонтрагентов.Ссылка
|ИЗ
| Справочник.ДоговорыКонтрагентов КАК ДоговорыКонтрагентов
|ГДЕ
| ДоговорыКонтрагентов.Владелец = &Владелец
| И ДоговорыКонтрагентов.Организация = &Организация
| И ДоговорыКонтрагентов.ВидДоговора = &ВидДоговора
| И ДоговорыКонтрагентов.ПометкаУдаления = ЛОЖЬ";
Запрос.УстановитьПараметр("Владелец", СвойстваПоиска["Владелец"]);
Запрос.УстановитьПараметр("Организация", СвойстваПоиска["Организация"]);
Запрос.УстановитьПараметр("ВидДоговора", Перечисления.ВидыДоговоров.СПокупателем); // Или значение из СвойстваПоиска
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Если Выборка.Следующий() Тогда
СсылкаНаОбъект = Выборка.Ссылка;
ПрекратитьПоиск = Истина;
КонецЕсли;
КонецЕсли;
Использование ПрекратитьПоиск = Истина позволяет полностью перехватить управление у стандартного механизма КД. Мы сами определяем логику: искать ли только «живые» (не помеченные на удаление) объекты, учитывать ли дополнительные свойства или выбирать договор по определенному приоритету.
Важно помнить, что по умолчанию КД 2.0 всегда сначала пытается найти объект по GUID (UID). Если вы переносите данные между базами 8.х, которые не являются родственными, поиск по UID может сработать непредсказуемо (например, если объект с таким же GUID существует, но это совершенно другой договор). Чтобы система сразу переходила к поиску по владельцу, в настройках ПКО на закладке Основные следует снять флаг Искать объект по уникальному идентификатору.
Примечание для обменов с 7.7: При выгрузке из 1С 7.7 в 1С 8.х поиск по UID технически невозможен в том виде, в котором он реализован в «восьмерке», поэтому там поиск всегда идет по полям, указанным в правилах.
Мы выяснили, что синхронизация только по владельцу технически возможна, но таит в себе бухгалтерские риски. Чтобы обеспечить надежность переноса, следуем алгоритму:
Владельцу, Организации и Виду договора.Такой подход позволит корректно «подцепить» остатки к уже существующей нормативно-справочной информации, не создавая дублей и не нарушая аналитику учета в базе-приемнике.