При обмене данными между конфигурациями 1С, особенно когда мы используем механизм «Конвертация данных 2» (КД2) и планы обмена, одна из наиболее распространенных и неприятных проблем — это появление сообщения «Объект не найден» для справочных данных, таких как контрагенты и договоры. Это происходит даже в тех случаях, когда мы уверены, что эти объекты уже существуют в базе-приемнике. Разберем эту ситуацию подробнее, выясним причины и предложим пошаговые решения.
Давайте представим следующую ситуацию: у нас есть сильно измененная база УТ 10.3, и мы хотим перегрузить из нее «Заказы клиентов» в базу 1С:ERP. Контрагенты и договоры в ERP уже присутствуют, поскольку были загружены из другой базы 1С:Бухгалтерия. При этом, если мы выгружаем заказы в ручном режиме через «универсальный обмен данными», все объекты находятся корректно. Однако, как только мы начинаем использовать новый план обмена, настроенный в КД2, контрагенты и договоры в загруженных заказах в ERP внезапно становятся «Объект не найден».
Эта проблема чаще всего указывает на некорректную настройку правил поиска объектов в КД2, когда механизм обмена не может правильно сопоставить полученные данные с уже имеющимися в базе-приемнике. Возможно, система сначала пытается искать по уникальному идентификатору (УИД), а затем, не найдя по нему, не переходит к поиску по другим полям или делает это некорректно.
Прежде чем перейти к решениям, рассмотрим основные причины, по которым возникает такая ситуация:
Некорректная настройка правил поиска. Это наиболее частая причина. Если в правилах конвертации объектов (ПКО) неверно заданы поля поиска или приоритет поиска, система просто не сможет найти уже существующий объект.
Привязка к УИД в неподходящих сценариях. Уникальный идентификатор (УИД) — это внутренний идентификатор объекта в конкретной базе данных. Если мы обмениваемся с пустой базой, где все объекты должны создаваться и получать новые УИД из источника, то поиск по УИД оправдан. Но если в базе-приемнике уже есть объекты, поиск по УИД может привести к проблемам, так как УИД объекта в источнике может не совпадать с УИД того же логического объекта в приемнике (если он был создан независимо или из другого источника).
Флаг «Не создавать новый объект в приемнике, если он НЕ найден». Этот флаг в ПКО напрямую влияет на поведение системы. Если объект не найден по заданным правилам поиска, и этот флаг установлен, система не будет создавать новый объект, а вместо него подставит «Объект не найден».
Отсутствие явной конвертации зависимых объектов. Договоры, банковские счета, контактные лица — это зависимые объекты контрагента. Они не найдутся автоматически, если для них не прописаны отдельные правила конвертации или если их связь с владельцем (контрагентом) не обрабатывается корректно.
«Очистка» данных синхронизацией. В отличие от универсального обмена, который просто загружает данные, синхронизация через планы обмена может иметь более сложную логику, включая удаление или изменение объектов, если правила настроены неточно. Важно проверять вкладку «Удаляемые объекты» в правилах.
Проблемы с ссылочной целостностью или правами доступа. Хотя и реже, но битые ссылки в базе или недостаточные права пользователя на просмотр объекта также могут приводить к сообщению «Объект не найден».
Давайте рассмотрим, как правильно настроить правила поиска, чтобы избежать проблем с «Объект не найден».
Когда мы работаем с базами, в которых уже есть контрагенты, крайне не рекомендуется полагаться только на поиск по УИД. УИД — это внутренний уникальный идентификатор, который генерируется при создании объекта в конкретной информационной базе. Если контрагент был изначально создан в одной базе, а затем загружен в другую (например, из БП в ЕРП), его УИД в ЕРП может отличаться от УИД того же контрагента в УТ, даже если это логически один и тот же контрагент. Использование УИД для поиска в таких сценариях может привести к тому, что система не найдет существующий объект, и либо создаст дубликат, либо выдаст «Объект не найден».
В Правилах конвертации объектов (ПКО) для справочника Контрагенты (и других справочников, которые могут существовать в обеих базах) мы должны снять флаг Искать объект приемника по внутреннему идентификатору объекта источника. Этот флаг должен использоваться только тогда, когда мы уверены, что база-приемник пустая, и мы хотим, чтобы УИД объектов сохранялся при обмене, чтобы поддерживать уникальность между источником и приемником.
После того как мы отказались от приоритетного поиска по УИД, нам необходимо настроить надежный поиск по ключевым реквизитам. Для большинства юридических лиц таким ключевым реквизитом является ИНН, часто в сочетании с КПП. Для физических лиц или случаев, когда ИНН может отсутствовать (например, у некоторых иностранных контрагентов или маркетплейсов), основным полем поиска становится Наименование.
В ПКО для Контрагенты установите флаг Продолжить поиск по полям поиска, если по идентификатору объект приемник не найден. Далее в разделе «Поля поиска» укажите следующие реквизиты:
ИНН: Для юридических лиц это основной и наиболее надежный идентификатор. Убедитесь, что ИНН всегда заполнен в обеих базах.
КПП: Дополнительный идентификатор для юридических лиц, который помогает уточнить поиск, если у одного ИНН есть несколько КПП (что бывает редко, но возможно).
Наименование: Важен для физических лиц, а также как резервный вариант для юридических лиц, если ИНН по какой-либо причине отсутствует или неверен. Однако будьте осторожны: наименования могут быть неточными, содержать лишние символы, что затруднит поиск. Для более надежного поиска по наименованию можно использовать обработчики событий (см. ниже).
Пример настройки полей поиска в КД2:
Открываем Правила конвертации объектов (ПКО) для справочника Контрагенты.
// В конфигурации "Конвертация данных 2.0" или "3.0"
// Переходим на вкладку "Поиск объектов"
// Снимаем флаг: "Искать объект приемника по внутреннему идентификатору объекта источника"
// Устанавливаем флаг: "Продолжить поиск по полям поиска, если по идентификатору объект приемник не найден"
// Добавляем поля для поиска:
// 1. Поле: ИНН, Тип: Строка, Свойство источника: ИНН, Свойство приемника: ИНН
// 2. Поле: КПП, Тип: Строка, Свойство источника: КПП, Свойство приемника: КПП
// 3. Поле: Наименование, Тип: Строка, Свойство источника: Наименование, Свойство приемника: Наименование
Этот флаг является одним из критически важных для сценария, когда мы получаем «Объект не найден». Если объект не найден по заданным правилам поиска (ни по УИД, ни по полям поиска), система должна решить, что делать дальше: создать новый объект или сообщить об ошибке. Если флаг Не создавать новый объект в приемнике, если он НЕ найден установлен, и объект не был найден, то вместо ссылки на объект в документе появится «Объект не найден», а сам объект создан не будет.
Если в вашем случае контрагенты уже существуют в базе ERP, и вы хотите, чтобы система их находила, то основное внимание должно быть уделено правильной настройке полей поиска. Однако, если после всех настроек поиска объект все равно не находится, и вы хотите, чтобы система создавала его в качестве нового, если он действительно отсутствует, то снимите этот флаг. Это позволит системе создать новый контрагент, если он не был найден по существующим правилам. Но будьте предельно осторожны: это может привести к появлению дубликатов, если объект на самом деле существует, но правила поиска настроены неточно.
В некоторых случаях стандартных полей поиска может быть недостаточно. Например, если наименование контрагента может варьироваться (полное, сокращенное, с разными символами), или требуется сложная логика сопоставления. Для таких сценариев мы можем использовать обработчики событий в ПКО, например, обработчик После загрузки.
В этом обработчике можно реализовать собственный алгоритм поиска, который будет выполнять более гибкое сопоставление, например, с учетом частичного совпадения наименований, групп справочника или других вспомогательных реквизитов. Например, можно сначала искать по ИНН, а если не найдено — по обрезанному или нормализованному наименованию.
// Пример обработчика "После загрузки" в ПКО для Контрагенты
// Этот код будет выполнен после попытки загрузки/поиска объекта
Процедура ПослеЗагрузки(ОбъектПриемник, ОбъектИсточник, Отказ, ЗамещаемыйОбъект)
Если ОбъектПриемник.Пустая() И НЕ Отказ Тогда // Если объект не был найден или создан
// Попытка найти по ИНН и Наименованию, если стандартный поиск не сработал
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| Контрагенты.Ссылка
|ИЗ
| Справочник.Контрагенты КАК Контрагенты
|ГДЕ
| (Контрагенты.ИНН = &ИНН И Контрагенты.КПП = &КПП)
| ИЛИ (Контрагенты.ИНН = &ИНН И &КПП = """") // Если КПП в источнике не заполнено
| ИЛИ (ВЫБОР
| КОГДА &ИНН = """"
| ТОГДА СТРОКА(Контрагенты.Наименование) ПОДОБНО &НаименованиеПоиск + ""%""
| ИНАЧЕ ЛОЖЬ
| КОНЕЦ)";
Запрос.УстановитьПараметр("ИНН", ОбъектИсточник.ИНН);
Запрос.УстановитьПараметр("КПП", ОбъектИсточник.КПП);
// Для более гибкого поиска по наименованию можно использовать функции
Запрос.УстановитьПараметр("НаименованиеПоиск", ОбъектИсточник.Наименование);
РезультатЗапроса = Запрос.Выполнить();
Если НЕ РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
ОбъектПриемник = Выборка.Ссылка; // Присваиваем найденную ссылку
Отказ = Ложь; // Указываем, что объект найден
Иначе
// Если объект все еще не найден и мы не хотим его создавать, можно установить Отказ = Истина
// или позволить системе создать новый, если флаг "Не создавать..." снят
КонецЕсли;
КонецЕсли;
КонецПроцедура
Такой подход позволяет реализовать очень специфичную логику сопоставления, выходящую за рамки простых настроек полей.
Проблема «Объект не найден» часто касается не только самих контрагентов, но и их зависимых объектов, таких как договоры. Важно понимать, что эти объекты не найдутся автоматически. Каждый зависимый объект (Договоры контрагентов, Банковские счета, Контактные лица и т.д.) должен быть явно включен в правила обмена и иметь свои собственные правила поиска и конвертации свойств.
Для корректной передачи и поиска контрагента, мы должны убедиться, что в Правилах конвертации свойств (ПКС) для Контрагента (и для других справочников) явно указаны и сопоставлены все необходимые реквизиты. Это включает не только Наименование, ИНН, КПП, но и ПолноеНаименование, ВидКонтрагента, ЮрФизЛицо и другие. Если некоторые реквизиты не будут переданы, это может привести к неполным данным в приемнике или ошибкам при записи объекта.
Особое внимание уделите перечислениям и другим связанным справочникам. Например, если у Контрагента есть реквизит ВидКонтрагента, который ссылается на перечисление или справочник, то этот справочник/перечисление также должен быть включен в правила выгрузки и конвертации. Иначе система не сможет найти или создать соответствующее значение для реквизита ВидКонтрагента, и при записи объекта могут возникнуть ошибки или реквизит останется незаполненным.
Если мы синхронизируем свойства справочника рекурсивно, это означает, что система будет пытаться подтянуть все связанные справочники и перечисления. Убедитесь, что для этих связанных объектов также существуют или корректно создаются ПКО и ПКС.
В КД2 существует мощный механизм передачи параметров между различными частями правил конвертации (ПВД, ПКО, ПКС). Мы можем использовать Переменные Параметры, ИсходящиеДанные, ВходящиеДанные и ПараметрыОбъекта для передачи вспомогательных данных. Это особенно полезно, когда нужно дозаполнить необходимые реквизиты программно, например, установить значение по умолчанию, или передать контекст из родительского объекта в дочерний.
Например, при конвертации ДоговораКонтрагента, мы можем передать уже найденного или созданного Контрагента через параметры, чтобы явно связать договор с его владельцем.
// В обработчике "ПередВыгрузкой" для Контрагента
// Добавляем найденного контрагента в ИсходящиеДанные, чтобы он был доступен для его договоров
ИсходящиеДанные.Вставить("КонтрагентВладелец", Источник);
// В обработчике "ПослеЗагрузки" для ДоговораКонтрагента
// Получаем КонтрагентаВладельца из ВходящихДанных
Если ВходящиеДанные.Свойство("КонтрагентВладелец") Тогда
ОбъектПриемник.Владелец = ВходящиеДанные.КонтрагентВладелец;
КонецЕсли;
Важно понимать, почему универсальный обмен может работать, а синхронизация через планы обмена — нет. Универсальный обмен данными в формате XML — это, по сути, инструмент для разовой выгрузки/загрузки. Он может быть более «прощающим» к отсутствию точных правил поиска, так как его основная задача — перенести данные. Он часто не имеет такой сложной логики сопоставления и «очистки», как планы обмена.
Синхронизация данных, напротив, предназначена для постоянного, регулярного обмена между базами. Она обычно использует формат EnterpriseData, который включает метаинформацию о префиксах информационных баз, механизмах регистрации изменений и более строгих правилах сопоставления и обработки данных. Механизм синхронизации через планы обмена более требователен к точности настроек КД2, поскольку он подразумевает поддержание целостности данных в двух или более базах на постоянной основе. Если правила поиска настроены неточно, этот механизм может либо создавать дубликаты, либо, как в нашем случае, выдавать «Объект не найден», либо даже «подчищать» (удалять) объекты, которые он считает не соответствующими.
Давайте разберем по шагам, как настроить обмен, чтобы избежать проблем с «Объект не найден» для контрагентов и договоров.
Резервное копирование. Прежде чем вносить любые изменения в правила обмена или конфигурацию, всегда делайте полную резервную копию обеих информационных баз. Это критически важно для возможности восстановления в случае непредвиденных проблем.
Анализ существующих контрагентов в ЕРП. Убедитесь, что контрагенты, которые должны быть сопоставлены, действительно существуют в базе ЕРП и имеют заполненные ключевые реквизиты (ИНН, КПП, Наименование). Проверьте их на наличие дубликатов.
Открытие Правил конвертации объектов (ПКО) для Контрагенты. Запустите конфигурацию Конвертация данных 2.0/3.0 и откройте правила обмена, которые вы используете. Найдите ПКО для справочника Контрагенты.
Настройка поиска для Контрагенты:
Отключите поиск по УИД: Снимите флаг Искать объект приемника по внутреннему идентификатору объекта источника. Это очень важный шаг, так как УИД мог измениться при загрузке из БП в ЕРП.
Включите поиск по полям: Установите флаг Продолжить поиск по полям поиска, если по идентификатору объект приемник не найден.
Добавьте ключевые поля поиска: В списке полей поиска укажите:
ИНН: Для юридических лиц это приоритетный идентификатор. Убедитесь, что ИНН является строковым значением и соответствует данным в источнике и приемнике.
КПП: Дополнительный идентификатор для юридических лиц, работающий в связке с ИНН.
Наименование: Используйте как резервный вариант, особенно для физических лиц, или если ИНН отсутствует. При необходимости используйте нормализацию наименований в обработчиках событий для повышения точности.
Критический момент: Снимите флаг Не создавать новый объект в приемнике, если он НЕ найден. Это позволит системе создать новый контрагент, если по каким-либо причинам существующий не был найден. Это предотвратит ошибку «Объект не найден» в документе, хотя потенциально может привести к дубликатам, если настройки поиска были неоптимальными. После того, как вы убедитесь, что все контрагенты корректно находятся или создаются, можно будет решить, оставлять ли этот флаг снятым или установить его обратно и донастроить поиск.
Настройка правил конвертации свойств (ПКС) для Контрагенты:
Явно укажите все необходимые реквизиты: Перейдите на вкладку Правила конвертации свойств и убедитесь, что для Контрагента сопоставлены все важные реквизиты, такие как ИНН, КПП, ПолноеНаименование, ВидКонтрагента, ЮрФизЛицо и другие, которые используются в УТ и необходимы в ЕРП.
Включите связанные справочники и перечисления: Если у контрагента есть реквизиты, ссылающиеся на другие справочники или перечисления (например, ВидыКонтрагентов, ГруппыДоступа, СтраныМира), убедитесь, что для этих объектов также созданы или активированы ПКО и ПКС, и они участвуют в обмене. Иначе эти реквизиты останутся незаполненными или вызовут ошибки.
Настройка поиска и свойств для ДоговорыКонтрагентов:
Создайте или проверьте ПКО для ДоговорыКонтрагентов. Договоры — это отдельные объекты, и для них также нужно настроить поиск.
Настройте поиск по комбинации полей: Для договоров часто используется комбинация Владелец (Контрагент), Наименование, ВидДоговора, Номер, Дата. Убедитесь, что поиск по Владельцу настроен правильно и ссылается на уже найденного (или созданного) контрагента.
Явно укажите реквизиты договора: Сопоставьте все необходимые реквизиты договора (Номер, Дата, ВалютаВзаиморасчетов, ВидДоговора и т.д.).
Проверка вкладки «Удаляемые объекты». В правилах обмена на вкладке «Удаляемые объекты» убедитесь, что список пуст, если вы не планируете удалять объекты в приемнике при обмене. Неверная настройка здесь может привести к нежелательной «очистке» данных.
Тестирование обмена. После всех настроек, не запускайте полный обмен сразу. Протестируйте обмен на небольшом количестве заказов, для которых вы уверены в данных. Внимательно проверьте загруженные документы в ЕРП: корректно ли проставились контрагенты и договоры, нет ли дубликатов.
Тестирование и исправление ИБ. Если вы подозреваете, что в базе-приемнике могли возникнуть внутренние проблемы со ссылочной целостностью, используйте встроенные инструменты 1С: Администрирование -> Тестирование и исправление. Выбирайте опции «Проверка логической целостности» и «Проверка ссылочной целостности». Если будут найдены «битые» ссылки, система предложит варианты исправления: «Создавать объекты» (создаст новые объекты для битых ссылок), «Очищать ссылки» (удалит ссылки), или «Не изменять».
Ручное сопоставление данных. В некоторых сложных случаях, когда автоматический поиск все равно не дает желаемого результата, может потребоваться ручное сопоставление. В системах 1С (особенно в конфигурациях, поддерживающих EnterpriseData) существуют регистры сведений, например, Публичные идентификаторы синхронизируемых объектов (или аналогичные), которые позволяют вручную указать соответствие УИД объектов между базами. Это трудоемкий процесс, но он может быть последним шагом для критически важных объектов.
Следуя этим подробным рекомендациям, мы значительно повысим вероятность успешного обмена данными и избежим проблем с «Объект не найден», обеспечив корректное функционирование наших информационных систем.