При настройке обмена данными между базами 1С через универсальный формат EnterpriseData (ED) разработчики часто сталкиваются с нетривиальной задачей: необходимо добавить в обмен совершенно новый, нетиповой объект метаданных (например, самописный справочник или документ).
Рассмотрим типичную ситуацию: вы добавили правила для нового объекта в XDTO, прописали алгоритмы в общем модуле МенеджерОбменаЧерезУниверсальныйФормат (добавили ПОД и ПКО), включили объект в план обмена. В отладчике видно, что объект регистрируется и попадает в процедуры выгрузки. Однако при формировании итогового XML-файла появляется только заголовок с типом объекта, а сами данные (свойства и реквизиты) не выгружаются — тег свойств оказывается пустым.
Проанализируем эту ситуацию и разберем по шагам, почему так происходит и как заставить систему корректно формировать XML-файл с данными вашего нового объекта.
Если в выгруженном файле вы видите блок объекта, но теги внутри него пустые (или отсутствует секция ObjectProperties), в первую очередь обратим внимание на правила конвертации свойств. ПКО (правила конвертации объектов) лишь говорят системе о том, что объект нужно обработать, но не объясняют, как именно разбирать его реквизиты.
В модуле МенеджерОбменаЧерезУниверсальныйФормат внутри процедуры инициализации ПКО нового объекта необходимо явно описать алгоритмы выгрузки свойств. Для каждого реквизита должен быть вызван метод ДобавитьПКС. Если эти алгоритмы отсутствуют, закомментированы или возвращают пустые значения, платформа не сгенерирует вложенные узлы в XML.
Выясним причину на уровне настроек узла. Универсальный формат строго версионируется. Существуют версии 1.14, 1.15, 1.16 и так далее.
Предположим, вы расширили пакет XDTO для версии 1.16 и описали новый объект именно там. Однако в настройках конкретного узла плана обмена в режиме Предприятия установлена работа по версии 1.14. В этом случае система успешно "увидит" регистрацию вашего документа или справочника, попытается его выгрузить, но не найдет подходящих правил и структуры в схеме версии 1.14. В результате секция данных останется пустой, так как система не знает, как сериализовать этот объект для старой версии формата. Обязательно проверьте версию обмена в узле!
В современных конфигурациях 1С не рекомендуется снимать типовой пакет XDTO с поддержки для прямого редактирования. Правильным подходом является создание расширения формата. Если вы пошли этим путем, пакет необходимо правильно инициализировать.
Разберем, что нужно сделать:
ОбменДаннымиПереопределяемый найдите процедуру ПриПолученииДоступныхРасширенийФормата. В ней нужно прописать URI пространства имен вашего добавленного пакета XDTO.ПространствоИмен.ОбменДаннымиXDTOСервер.ИнициализироватьРасширениеПравилаКонвертацииОбъекта.Если пропустить этот шаг, платформа 1С просто не поймет, в каком пространстве имен необходимо генерировать XML-теги свойств, и оставит блок данных пустым, не выдав при этом явной ошибки.
Как обсуждалось на форуме, важно убедиться, что объекты физически регистрируются на узле. Если в макете правил регистрации (или в узле обмена) объект не прописан корректно, он не попадет в выборку.
Посмотрим на механизм авторегистрации: для стабильной работы необходимо добавить ваш новый объект метаданных в состав источников типовых подписок на события. Ищите подписки с именами вроде СинхронизацияДанныхЧерезУниверсальныйФорматРегистрацияДокумента или аналогичные для справочников. Без этого изменения в объектах не будут фиксироваться в таблицах регистрации плана обмена.
Дописывать код конвертации вручную непосредственно в модуль МенеджерОбменаЧерезУниверсальныйФормат — это сложный, трудоемкий процесс, чреватый ошибками из-за опечаток или пропущенных связей. Оптимальный и рекомендуемый фирмой 1С путь заключается в использовании конфигурации "1С:Конвертация данных 3" (КД 3).
Рассмотрим алгоритм работы с КД 3:
Такой подход гарантирует, что все обязательные процедуры (включая ВыполнитьПроцедуруМодуляМенеджера) и вызовы будут сформированы без синтаксических и логических ошибок.
Если задача заключается в передаче пары дополнительных реквизитов или простого объекта, и вы хотите избежать сложной работы с XDTO-пакетами и расширениями, проанализируем "лайфхак" с использованием штатного поля.
Любой базовый объект (тип Object) в формате EnterpriseData имеет свойство AdditionalInfo. Это поле предназначено для передачи произвольной информации. Вы можете сериализовать данные вашего нового объекта (например, в JSON или структуру) и в процедуре ПриОтправкеДанных поместить их в это поле.
На стороне базы-приемника, в процедуре при получении данных, вы просто считываете содержимое AdditionalInfo, десериализуете его и программно создаете или обновляете нужный объект. Это значительно экономит время на доработку формата.
Наконец, помните: любая выгрузка бессмысленна без симметричной загрузки. Все новые объекты, добавленные в XDTO, и измененные правила выгрузки требуют аналогичной настройки (ПОД и ПКО для загрузки) на стороне базы-получателя. Если в приемнике нет алгоритмов обработки ваших новых тегов, система либо проигнорирует их, либо, при строгой валидации XDTO-схемы, выдаст ошибку чтения XML-файла.
Следуя этим шагам, вы сможете точно локализовать проблему пустых файлов и корректно встроить новые объекты в синхронизацию через EnterpriseData. Для контроля результата и поиска расхождений в данных после настройки обмена можно автоматически сверять бухгалтерские и налоговые проводки между базами 1С.