При работе с инструментом «Конвертация данных 2.1» программисты часто сталкиваются с ситуацией, когда при обмене данными между современными конфигурациями (например, ЗУП 3.1, ERP 2.5 или БП 3.0) некоторые поля выгружаются некорректно. Одной из наиболее «коварных» проблем является отсутствие значения УникальныйИдентификатор в файле выгрузки XML. Особенно остро это проявляется, когда объект (справочник, документ), который мы пытаемся передать, был создан не в основной конфигурации, а в расширении.
Рассмотрим подробнее, почему проверенный годами механизм дает сбой и как нам совместно решить эту задачу, используя программные методы и настройки правил конвертации.
Давайте разберем ситуацию с технической точки зрения. Релиз конфигурации Конвертация данных 2.1.8.2 и сопутствующие ей обработки выгрузки (MD83Exp.epf, V8ExSrv.epf) выпускались в то время, когда механизм расширений в платформе «1С:Предприятие 8.3» находился в зачаточном состоянии. Логика формирования XML-файла в универсальной обработке обмена построена на стандартной сериализации и обращении к метаданным.
Когда объект создан в расширении, его тип в пространстве имен XML отличается от стандартных объектов основной конфигурации. Устаревшие версии обработки Универсальный обмен данными XML просто «не понимают», что перед ними полноценный ссылочный объект, обладающий уникальным идентификатором, и пропускают заполнение узла {УникальныйИдентификатор}. В итоге в приемнике создаются дубли или объекты с «битыми» ссылками, так как поиск по идентификатору становится невозможным.
Если мы не можем обновить саму обработку выгрузки (например, из-за жестких ограничений среды), мы можем заставить систему выгрузить UUID принудительно. Разберем по шагам, как это реализовать в правилах обмена:
{УникальныйИдентификатор} (обязательно в фигурных скобках). Это системное имя, которое обработка обмена ищет при загрузке.Пропишем следующий код, который принудительно вычислит идентификатор ссылки и передаст его в значение свойства:
// Явно получаем GUID из ссылки источника
Значение = Строка(Источник.Ссылка.УникальныйИдентификатор());
Этот простой прием гарантирует, что в XML-файле появится узел с корректным строковым представлением идентификатора. Важно помнить, что мы используем функцию Строка() или метод УникальныйИдентификатор(), чтобы передать именно значение, которое приемник сможет распознать.
Выясним еще одну важную деталь: как именно мы загружали метаданные в КД 2.1? Если вы использовали старую обработку MD82Exp.epf, она в принципе не увидит объекты из расширений. Для корректной работы необходимо использовать MD83Exp.epf актуальной версии.
Проанализируем алгоритм правильной подготовки правил:
MD83Exp.epf в базе-источнике (где есть расширение).xml с описанием конфигурации в КД 2.1.Однако даже при наличии свежих метаданных, проблема с выгрузкой данных в старых версиях УОД (Универсальный обмен данными) может сохраняться. Поэтому программный метод из Способа 1 остается наиболее надежным "костылем".
Давайте посмотрим на ситуацию глобально. Технология Конвертация данных 2.1 основана на жесткой структуре метаданных. Фирма «1С» уже давно развивает Конвертацию данных 3.x, которая работает через формат Enterprise Data. В этой парадигме обмен идет через XDTO-пакеты.
Преимущества перехода для объектов из расширений:
UID — это просто одно из полей типа string.Если ваша задача — разовый перенос, используйте Способ 1. Если вы планируете долгосрочное развитие системы с множеством расширений, настоятельно рекомендуем рассмотреть переход на КД 3.1.
Проанализируем еще несколько моментов, которые могут помешать успешной выгрузке:
Режим совместимости: Если ваша конфигурация работает в режиме совместимости ниже 8.3.10, работа с типами данных из расширений может быть нестабильной на уровне платформы. Убедитесь, что платформа обновлена, а режим совместимости позволяет использовать современные механизмы сериализации.
Область видимости: Иногда программисты пытаются обращаться к объектам расширения из кода основной конфигурации (например, в модуле обмена). Помните, что основная конфигурация «не знает» о типах данных расширения, если не включена соответствующая настройка в свойствах расширения. Однако обработка обмена, запущенная в контексте всей базы, обычно имеет доступ ко всем данным.
Мы выяснили, что отсутствие Уникального Идентификатора — это не ошибка ваших действий, а следствие архитектурного разрыва между старым инструментом КД 2.1 и новым механизмом Расширений. Чтобы решить проблему здесь и сейчас, используйте добавление ПКС {УникальныйИдентификатор} с явным присвоением Значение = Источник.Ссылка.УникальныйИдентификатор(). Это гарантирует целостность данных при миграции и избавит вас от дублей в базе-приемнике.