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