Интеграция с 1С:Документооборот: как расширить правила библиотеки интеграции

Интеграция с 1С:Документооборот через встроенную библиотеку настраивается правилами в справочнике «Правила интеграции с 1С:Документооборотом»: какой документ ДО создавать и чем заполнять его поля. Но выражения в правилах выполняются в контексте учётной системы, и заполнить поле карточки по данным самого ДО (например, поставить ответственным руководителя организации из справочников ДО) штатно нельзя. Решение — добавить в модель обмена своё свойство «обработка перед записью», настраивать его в правилах и выполнять соответствующую логику на стороне ДО прямо перед записью карточки.

Ниже — пошаговая схема доработки обеих сторон и безопасный вариант реализации: передаём не код, а имя обработчика.

Ограничение стандартных правил

Правило интеграции описывает соответствие: реквизит документа ДО ← реквизит учётного документа, константа или выражение. Это удобно, пока данные для заполнения есть в учётной системе.

Пример задачи: из «Поступления товаров» в Бухгалтерии создаётся внутренний документ в ДО, и ответственным нужно поставить руководителя организации — по данным ответственных лиц, которые ведутся в ДО. Учётная система этих данных не знает, а в правиле нет события «перед записью в ДО», как было, например, в правилах конвертации КД 2.0.

Идея доработки

1. В модели данных интеграции (XDTO-пакет DM на стороне ДО) у объекта документа появляется новое строковое свойство, например BeforeWriting.
2. В учётной системе это свойство показывается в правилах заполнения как дополнительный реквизит, его значение можно задать в правиле.
3. Значение уходит в ДО вместе с данными документа.
4. ДО при записи карточки, внутри транзакции, видит свойство и выполняет соответствующую обработку.

В исходном варианте этого приёма в свойство передают фрагмент кода и выполняют его методом Выполнить(). Я так не делаю и ниже объясню почему.

Шаг 1. ДО: новое свойство в модели обмена

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

Необязательность важна: учётные базы без доработки должны продолжать работать.

Изменение XDTO-пакета — это правка конфигурации ДО. Перед ней проверьте, как это повлияет на обновления: изменённый пакет придётся объединять при каждом обновлении ДО. Правки модулей, где возможно, выносите в расширение.

Шаг 2. Учётная система: поле в правилах

Учётной системе тоже нужно знать о новом свойстве. В модуле менеджера справочника правил интеграции есть функция, формирующая список реквизитов объекта ДО для настройки правил (в версиях библиотеки, которые я дорабатывал, — ПолучитьРеквизитыОбъектаДО). Добавьте туда описание нового поля рядом с общими для всех типов документов полями — тогда оно появится на странице «Правила заполнения при отправке данных» у любого вида документа.

Дальше — передача значения:

• в форме обработки интеграции для нужного вида документа (например, внутреннего) добавьте реквизит формы ОбработкаПередЗаписьюВДО строкового типа; элемент на форму выводить не нужно;
• в функции соответствия свойств XDTO и реквизитов формы (в библиотеке — СоответствиеСвойствXDTOиРеквизитовФормыОбъектаДО) добавьте пару «реквизит формы ↔ BeforeWriting».

После этого значение, рассчитанное по правилу, попадёт в реквизит формы и будет передано в XDTO-объект при отправке.

Шаг 3. ДО: обработка перед записью

На стороне ДО запись документов при интеграции выполняет общий модуль обработки XDTO-запросов по документам. В нём есть отдельные функции для внутренних, входящих и исходящих документов. Сразу после начала транзакции записи, когда объект уже заполнен данными из пакета, вставьте вызов своей процедуры.

Безопасный вариант — передавать имя обработчика, а не код:

// Выполняет дополнительную обработку документа перед записью по имени обработчика,
// переданному из учетной системы в свойстве BeforeWriting.
Процедура ВыполнитьОбработкуПередЗаписью(ДокументОбъект, ОбъектXDTO) Экспорт

	ИмяОбработчика = "";
	Если ОбъектXDTO.Установлено("BeforeWriting") Тогда
		ИмяОбработчика = СокрЛП(ОбъектXDTO.BeforeWriting);
	КонецЕсли;

	Если Не ЗначениеЗаполнено(ИмяОбработчика) Тогда
		Возврат;
	КонецЕсли;

	Если ИмяОбработчика = "ОтветственныйРуководительОрганизации" Тогда
		ЗаполнитьОтветственногоРуководителем(ДокументОбъект);
	ИначеЕсли ИмяОбработчика = "ОтветственныйПоПодразделению" Тогда
		ЗаполнитьОтветственногоПоПодразделению(ДокументОбъект);
	Иначе
		ВызватьИсключение СтрШаблон(НСтр("ru = 'Неизвестный обработчик интеграции: %1'"), ИмяОбработчика);
	КонецЕсли;

КонецПроцедуры

Процедура ЗаполнитьОтветственногоРуководителем(ДокументОбъект)

	// Получение руководителя организации по данным ДО - своя функция,
	// например по сведениям об ответственных лицах организации
	Руководитель = ИнтеграцияУчетныхСистемДО.РуководительОрганизации(ДокументОбъект.Организация);
	Если ЗначениеЗаполнено(Руководитель) Тогда
		ДокументОбъект.Ответственный = Руководитель;
	КонецЕсли;

КонецПроцедуры

ИнтеграцияУчетныхСистемДО здесь — ваш общий модуль в расширении, а имена реквизитов документа сверьте со своей версией ДО.

Для проверки свойства используется Установлено() у объекта XDTO: если учётная база старая и свойство не передала, обращение к нему не упадёт.

Не забудьте вставить вызов во все функции записи для тех видов документов, где он нужен. Если хотите, чтобы рассчитанное значение вернулось на форму интеграции в учётной системе, оно вернётся вместе с данными записанного документа, как и остальные поля.

Шаг 4. Настройка правила

В учётной базе откройте правило интеграции, на странице заполнения найдите новое поле и задайте ему значение-константу, например ОтветственныйРуководительОрганизации. Можно и выражение — тогда имя обработчика будет зависеть от данных учётного документа.

Шаг 5. Проверка

1. Создайте документ ДО на основании учётного документа из формы интеграции.
2. Запишите — данные уйдут в ДО, там выполнится обработчик.
3. Проверьте, что в карточке ДО и в форме интеграции поле «Ответственный» заполнено по логике обработчика.
4. Проверьте сценарий с неизвестным именем обработчика: запись должна завершиться понятной ошибкой, а не тихо.

Почему не передавать исполняемый код

Вариант «передать строку кода и выполнить её Выполнить()» работает и выглядит гибко. Но веб-сервис интеграции принимает запросы от любого клиента с учётными данными интеграционного пользователя. Если ДО выполняет пришедший код, то любой, кто может отправить запрос, может выполнить произвольный код на сервере ДО: прочитать или удалить данные, обойти права. Даже при доверенной сети это плохая практика — логика размазывается по правилам в разных базах, её сложно найти, протестировать и обновить.

Список имён обработчиков даёт ту же гибкость для реальных задач, при этом:

• код живёт в ДО, под контролем версий и ревью;
• учётная система лишь выбирает, какую обработку применить;
• неизвестное имя — понятная ошибка, а не выполнение чего угодно.

Передавайте между системами данные и намерения, а не код. Логика должна жить там, где её можно проверить.

Что ещё можно расширить тем же способом

• Обработчики для входящих и исходящих документов, а не только внутренних.
• Обработка после записи: например, автоматический запуск процесса согласования.
• Обработка при заполнении документа на стороне ДО, до показа формы пользователю.

Доработки интеграции учётных систем с ДО и настройку правил делаю в рамках интеграции 1С с СЭД и внедрения 1С:Документооборот.

Итог

• Штатные правила интеграции не позволяют заполнять поля карточки ДО по данным самого ДО.
• Решение — новое необязательное свойство в XDTO-пакете DM, поле в правилах учётной системы и обработка перед записью в ДО.
• Передавайте имя обработчика, а не код: выполнение пришедшего кода — дыра в безопасности.
• Проверяйте свойство через Установлено(), чтобы недоработанные учётные базы продолжали работать.