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