Как передать нетиповые реквизиты при интеграции 1С:Документооборот и 1С:Бухгалтерия КОРП?

Разберем ситуацию, с которой часто сталкиваются разработчики при настройке бесшовной интеграции между 1С:Документооборот (ДО) и 1С:Бухгалтерия предприятия КОРП (БП). Допустим, на стороне ДО для внутреннего документа добавлены новые реквизиты через Конфигуратор (то есть это не типовые «Дополнительные реквизиты», созданные в режиме Предприятия). Возникает вопрос: что нужно доработать, чтобы на стороне БП можно было получить и обработать эти нетиповые реквизиты связанного внутреннего документа?

Проанализируем доступные варианты решения этой задачи, выясним причину ограничений типового механизма и рассмотрим по шагам способы реализации обмена.

Архитектура обмена и роль веб-сервиса DMService

Посмотрим на то, как устроена базовая интеграция. Бесшовная интеграция между ДО и БП КОРП работает через веб-сервис DMService (по аналогии с тем, как выполняется произвольный запрос во внешнюю базу 1С). В основе этого сервиса лежит XDTO-пакет DM, который жестко описывает структуру передаваемых данных (модель данных документооборота).

Если реквизит добавлен в конфигураторе, стандартные правила интеграции его просто не увидят. Система сериализует объекты строго по схеме XDTO. Поскольку вашего нового поля в пакете DM нет, оно игнорируется при выгрузке. Чтобы данные передавались, нам нужно либо изменить саму схему данных (XDTO), либо «спрятать» наши данные в уже существующие типовые поля схемы.

Вариант 1: Модификация XDTO-пакета (через расширение)

Рассмотрим первый путь — добавление новых полей непосредственно в XDTO-пакет. Это можно сделать через расширение конфигурации, однако здесь есть строгие правила, которые необходимо соблюдать:

1. При добавлении пакета XDTO в расширение нельзя просто так добавить поле в базовый объект. Необходимо использовать директиву импорта и наследование типов. Укажите, что ваш новый пакет унаследован от типового пакета DM, и расширяйте конкретный тип (например, DMDocument).
2. Критически важный нюанс: структура XDTO-пакетов отправляющей и принимающей стороны должна полностью совпадать. Если вы расширили XDTO-пакет в 1С:Документооборот, вам обязательно нужно перенести точно такое же расширенное описание XDTO-пакета в базу 1С:Бухгалтерия КОРП. Иначе при попытке десериализации (чтения) на стороне БП система выдаст ошибку о неизвестном свойстве.

После синхронизации пакетов потребуется программная доработка:

На стороне ДО: В расширении необходимо перехватить логику формирования ответа веб-сервиса DMService. В момент сборки объекта XDTO перед отправкой, программно заполните ваше новое поле значением из добавленного реквизита.

На стороне БП КОРП: Требуется доработать логику Библиотеки интеграции с Документооборотом (БИД). В момент чтения полученного XDTO-объекта нужно извлечь ваше свойство и присвоить его соответствующему реквизиту документа БП.

Вариант 2: Использование существующих свойств без изменения XDTO (Рекомендуемый)

Разберем альтернативный путь, который на практике является самым популярным и наименее болезненным. Чтобы не ломать XDTO-схемы и не поддерживать их синхронизацию между базами при каждом обновлении конфигураций, можно программно упаковать данные в уже существующие коллекции, например, в additionalProperties.

Вместо изменения структуры пакета мы делаем следующее:

1. На стороне ДО: При выгрузке документа мы перехватываем процесс сериализации. Значение нетипового реквизита преобразуем, например, в формат JSON, и помещаем в служебное строковое поле или коллекцию дополнительных свойств, которые уже существуют в стандартном XDTO-пакете DM.
2. На стороне БП: При загрузке документа мы перехватываем входящие данные, аккуратно читаем наш JSON из служебного поля, парсим его и разносим полученные значения по нужным реквизитам карточки в БП.

Пример логики упаковки данных (псевдокод для общего понимания механики на стороне ДО):

// Формируем структуру с нашими нетиповыми реквизитами
ДанныеРеквизитов = Новый Структура;
ДанныеРеквизитов.Вставить("МойНетиповойРеквизит", ОбъектДО.МойНетиповойРеквизит);

// Сериализуем в JSON
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ДанныеРеквизитов);
СтрокаJSON = ЗаписьJSON.Закрыть();

// Помещаем в доступное свойство типового XDTO объекта (например, additionalProperties)
// XDTOОбъект - это формируемый пакет для отправки
XDTOОбъект.additionalProperties = СтрокаJSON;

Пример логики распаковки данных на стороне БП:

Если ЗначениеЗаполнено(XDTOОбъект.additionalProperties) Тогда
    // Пытаемся прочитать JSON
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(XDTOОбъект.additionalProperties);
    
    Попытка
        ДанныеРеквизитов = ПрочитатьJSON(ЧтениеJSON);
        // Заполняем реквизиты документа в БП
        Если ДанныеРеквизитов.Свойство("МойНетиповойРеквизит") Тогда
            ОбъектБП.МойНетиповойРеквизит = ДанныеРеквизитов.МойНетиповойРеквизит;
        КонецЕсли;
    Исключение
        // Обработка ошибок парсинга, если в поле пришло что-то другое
    КонецПопытки;
КонецЕсли;

Такой подход позволяет сохранить в неприкосновенности типовые XDTO-пакеты. Вы избежите конфликтов при обновлении типовых конфигураций и ошибок десериализации, так как структура XDTO остается неизменной, а все манипуляции с данными происходят исключительно на программном уровне внутри модулей обмена.