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