Состав синхронизируемых полей справочника Номенклатура (рис. 01)
Формат EnterpriseData
30.09.2023
Данная статья написана как демонстрация возможностей расширений пакетов XDTO и базируется на нескольких простых приемах, которые помогут понять процесс изменения формата обмена EnetrpriseData. Соответственно, в основу положены именно демонстрационные примеры того, как они работают, при этом теоретическому описанию уделено меньше внимания.
Прежде чем приступить к ознакомлению мы должны запомнить один важный момент: расширение пакета XDTO и расширение конфигурации это разные сущности. Это важно, потому что на начальном этапе возможна путаница. Так же, при описании проблематики расширений пакетов XDTO, мы описываем директивы импорта XSD-схем, т.к. XDTO пакет является естественным продолжением XSD-схемы в ценностях 1С.
С помощью данного механизма в большинстве случаев можно не снимать с поддержки поставляемые пакеты XDTO формата EnterpriseData, но при этом расширять их состав. Существенный нюанс: состав пакета можно только расширять, т.е. удалить или переименовать состав пакета невозможно, но в сценариях с обменами такие операции практически не востребованы.
Задача1.
Имеем типовую конфигурацию ERP (КА, УТ) версии 11.5.12, которая выгружает данные в аналогичную типовую конфигурацию. Нам нужно добавить дополнительные данные в синхронизацию, но при реализации задачи нам так же нужно сохранить правила поддержки, т.е. не снимать конфигурацию с поддержки. Справочник при выгрузке описан следующим составом полей:
Состав синхронизируемых полей справочника Номенклатура (рис. 01)
Далее нашей задачей будет добавить в состав синхронизируемых полей два свойства: МойКодКлассификации и ЕдиницаИзмеренияОтчетов, при этом, реквизит МойКодКлассификации необходимо добавить в ключевые поля.
Решение.
Возможно, самым рациональным решением было бы добавить свойства в структуру объекта формата, структуру при выгрузке упаковать в AdditionalInfo, а в приемнике, при загрузке, прочитать нашу структуру. И такой вариант можно рассмотреть, но если имеется много новых свойств или свойство разбросано по нескольким объектам формата, то работать через AdditionalInfo не удобно. К тому же не понятно, как отслеживать такие изменения при обновлениях. Со временем изменения в модуле менеджера обмена будут накапливаться и затраты на анализ добавленных свойств в коде будут расти с арифметической прогрессией.
Исходя из этого, рассмотрим альтернативный вариант решения задачи, который описан в данной статье.
Сначала добавим расширение конфигурации, и в расширении конфигурации добавим новые реквизит МойКодКлассификации справочника Номенклатура.
Расширение конфигурации (рис. 02)
Далее добавим пакет-XDTO, который будет расширять состав свойств объектов XDTO Справочник.Номенклатура и КлючевыеСвойстваСправочникНоменатура. В этой операции важно соблюсти последовательность и забрать в расширение конфигурации все объекты XDTO, которые мы планируем модифицировать.
Расширение формата (рис. 03)
Необходимо обратить внимание на директиву импорта, т.к. это ключевой момент. Обязательно нужно указать, что наш пакет-XDTO унаследован от типового. Это необходимо для того, чтобы сослаться на базовые объекты формата и, в дальнейшем, оперировать их свойствами. Поскольку пакет EnterpriseData_1_11_5 базируется на ExchangeMessage, так же необходимо забрать и его в расширение, иначе анализатор платформы выдаст ошибку проверки пакета. При этом XDTO-пакет EnterpriseData_1_11_5 нужно забрать со следующими объектами:
- Справочник.Номенклатура, потому что в этот объект мы добавляем свойство ЕдиницаИзмеренияОтчетов;
- КлючевыеСвойстваЕдиницаИзмерения, потому что в добавляемом свойстве ЕдиницаИзмеренияОтчетовуказываем базовый тип КлючевыеСвойстваЕдиницаИзмерения;
- КлючевыеСвойстваНоменклатура,
потому что в этот объект мы добавляем свойство МойКодКлассификации.
Новые свойства формата EnterpriseData (рис. 04.1 и 04.2)
После того, как свойства добавлены, нужно прописать наш XDTO-пакет в системе. Для этого нужно перейти в общий модуль ОбменДаннымиПереопределяемый и поправить процедуру ПриПолученииДоступныхРасширенийФормата. Чтобы не снимать с поддержки модуль процедуру необходимо добавить в расширение.
Инициализация расширенного XDTO-пакета (рис. 05)
После всех подготовительных работ нужно перейти непосредственно к моменту описания выгрузки самих свойств. Для этого необходимо использовать менеджер конвертации, а именно общий модуль МенеджерОбменаЧерезУниверсальныйФормат. Далее нужно поправить метод инициализации ПКО ДобавитьПКО_Справочник_Номенклатура_Отправка как показано на рисунке ниже. Основная задача - описать выгрузку новых свойств, при этом необходимо указать, в каком пространстве имен они будут выгружены.
Добавление в правила расширенных свойств XDTO-пакета (рис. 06)
Пространство имен, которое вы инициализировали, передается в параметр ПространствоИмен метода ДобавитьПКС(). Таким образом механизм запоминает, что свойство должно быть выгружено в пространстве имен, отличающемся от базового(см. рис. 07). 
Параметр ПространствоИмен (рис. 07)
Следует обратить внимание: в инициализации выгрузки свойств указано, что значение расширенных свойств будут получены алгоритмом (четвертый параметр равен 1, см. рис. 06). Поэтому после того, как мы поправили ПКО выгрузки номенклатуры, необходимо дописать в событие ПриОтправкеДанных получение значений дополнительных свойств.
Получение значений расширяемых свойств (рис. 08)
Если все предыдущие пункты выполнены правильно, то выгруженная номенклатура в файле сообщения будет содержать данные по расширенным свойствам. При этом такие узлы будут маркироваться соответствующим URI.
Сформированный xml с расширяемыми свойства (рис. 09)
При работе с расширениями рекомендуется делать одно расширение и для источника, и приемника, т.к. для системы важно обладать идентичным составом свойств, у которых обязательно должно совпадать пространство имен (URI). Порядок добавленных свойств тоже должен быть одинаков в двух информационных базах, иначе будет ошибка чтения файла. Обновление таких расширений можно делать через сравнение/объединение, или автоматизировать процесс установки/обновления расширений в нескольких ИБ при помощи пакетного режима работы 1С: Предприятия. Далее приступаем к загрузке. Начинаем с добавления нашего расширение в приемник. Поскольку в расширении уже есть изменения, которые инициализируют XDTO-пакет в общем модуле ОбменДаннымиПереопределяемый, мы начнем работу с правки ПКО загрузки справочника Номенклатура. Для этого переходим в метод ДобавитьПКО_Справочник_Номенклатура_Получение менеджера конвертации и добавим описание новых свойств.
Правила загрузки номенклатуры (рис.10)
Важно: реквизиты мы загружаем без использования алгоритма, т.е. прямым мапингом. Из-за этого нет необходимости изменять событие загрузки ПриКонвертацииДанныхXDTO. Строку с полями поиска тоже нужно оставить без изменений. Это потому, что сопоставление номенклатуры происходит только по уникальному идентификатору.
Это единственная правка, которая необходима для загрузки расширенных свойств, остальное подсистема сделает самостоятельно.
Результат загрузки номенклатуры (рис. 10.1)
Задача 2.
Продемонстрировать расширение состава свойств формата EnterpriseData для табличных частей. Для этого, на основе вышеописанного сценария, поправить выгрузку табличной части Товары документа Приобретение товаров услуг. Предположим, что у нас есть новое поле СрокГодности (тип Дата), которое надо выгружать с таблицей Товары.
Решение.
Для решения задачи нам нужно добавить поле СрокГодности в табличную часть Товары, вывести новое поле в форму.
Добавление нового поля (рис. 011.1 и 011.2)
По аналогии с решением в предыдущей задаче нам нужно перейти в пакет-XDTO и расширить свойства базового объекта формата, но есть один очень важный нюанс, который касается табличных частей и ключевых реквизитов.Эти объекты формата являются вложенными в основные, например, основной объект формата Справочник.Номенклатура содержит вложенный объект формата КлючевыеСвойства, при этом наличие расширений формата определяется по основному объекту формата. Соответственно, в расширение необходимо добавить основной объект формата, даже в том случае, когда в него не добавлено новых свойств. В первой задаче в объект формата Справочник.Номенклатура было добавлено свойство ЕдиницаИзмеренияОтчетов поэтому такой вопрос не возник.
Расширение формата табличного поля (рис. 012)
Далее необходимо поправить инициализацию ПКО. Для этого нужно внести изменения в метод ДобавитьПКО_Документ_ПоступлениеТоваровУслуг_Отправка.
Изменения ПКО выгрузки табличной части (рис. 013)
Для информации: чтобы листинг метода помещался в один экран, часть строк модуля заменены на точки, это только для иллюстрации.
Далее нам необходимо добавить в процедуру выборки данных новое поле. Для этого нужно изменить алгоритм ПТиУ_РасширенныеДанныеИБ(), который вызывается при работе обработчика ПриОтправкеДанных выгрузки документа. Поскольку алгоритм большой, то в статье демонстрируется только одна из правок.
Изменения алгоритма выборки данных (рис. 014)
После всех изменений данные о сроке годности будут добавлены в файл сообщения обмена.
Изменения ПКО загрузки (рис. 015)
Далее переходим к редактированию правил загрузки, но предварительно необходимо обновить расширение в приемнике.
В правилах загрузки нужно инициализировать реквизит СрокГодности. Необходимо указать, что обработка новых свойств будет выполнена алгоритмом.
Инициализация загрузки нового свойство табличной части (рис. 016)
В алгоритме необходимо обработать тестовое представление даты так, чтобы получить значение с типом Дата.
Изменения алгоритма загрузки (рис. 017)
После этого данные нового поля табличной части будут загружены в приемник.
Результат загрузки (рис. 018)
В заключении обращаем ваше внимание, что перед тестовыми прогонами необходимо убедиться, что объекты формата обмена, на которых вам нужно сделать доработки, входят в состав поддерживаемых объектом формата строго в двух ИБ (источника и приемника).