В процессе настройки комплексных процессов или правил обработки документов в 1С:Документооборот часто возникает задача: как сделать так, чтобы сотрудник, выполнивший задачу на одном этапе (например, согласование), автоматически назначался исполнителем на следующем этапе (например, исполнение поручения). Это особенно актуально, когда на первом этапе задача отправляется не конкретному лицу, а целой Роли (например, "Экономисты"), и нам нужно "поймать" именно того человека, который фактически взял документ в работу.
В этой статье мы подробно разберем, как реализовать этот механизм, используя программные возможности системы и справочник Алгоритмы автоподстановки. Мы рассмотрим логику поиска исполнителя через визы согласования и через задачи бизнес-процесса.
Прежде всего, проанализируем, где именно в системе происходит магия выбора исполнителя. В настройках действия (этапа обработки) в колонке "Исполнители" можно указывать не только конкретных пользователей или роли, но и объекты справочника АлгоритмыАвтоподстановки.
Когда система доходит до формирования задачи на определенном этапе, она запускает программный код, написанный в выбранном алгоритме. Этот код должен вернуть результат — конкретную ссылку на пользователя (или массив ссылок), который и станет исполнителем задачи. Главным входным параметром для такого скрипта всегда является переменная Источник, которая представляет собой сам документ (предмет процесса).
Если нам нужно найти того, кто согласовал документ на предыдущем этапе, самым логичным путем будет обращение к данным согласования. Рассмотрим ситуацию: у нас есть действие "Согласование с ПЭО", и нам нужно передать этого же сотрудника в действие "Задание в ПЭО".
Проанализируем программный код, который можно разместить в алгоритме автоподстановки. Нам потребуется выполнить запрос к данным виз согласования, привязанным к нашему предмету.
// Инициализируем запрос к данным виз
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ
| ВизыСогласования.Исполнитель КАК Исполнитель
|ИЗ
| Справочник.ВизыСогласования КАК ВизыСогласования
|ГДЕ
| ВизыСогласования.Владелец = &Источник
| И ВизыСогласования.РезультатСогласования = ЗНАЧЕНИЕ(Перечисление.РезультатыСогласования.Согласовано)
| И ВизыСогласования.Удалена = ЛОЖЬ
| И ВизыСогласования.РольИсполнителя.Наименование ПОДОБНО %ИмяРоли%";
Запрос.УстановитьПараметр("Источник", Источник);
Запрос.УстановитьПараметр("ИмяРоли", "Экономист");
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
Результат = Выборка.Исполнитель;
КонецЕсли;
Важный нюанс: если документ проходил несколько итераций (кругов) согласования, в справочнике ВизыСогласования может накопиться много записей. В таком случае стоит добавить условие по дате или номеру итерации, чтобы получить именно последнюю актуальную визу. Также обратите внимание на использование общей функции РаботаСВизамиСогласования.ПолучитьАктивныеВизыДокумента(Источник), которая может упростить получение коллекции объектов без прямого запроса.
Иногда использование виз может быть не совсем точным, особенно если в процессе участвуют роли и используется механизм "Взять в работу". Более надежный способ выяснить, кто именно работал с документом — найти завершенную задачу конкретного бизнес-процесса.
Разберем по шагам, как это работает:
Исполнитель в задаче меняется с Роли на конкретного Пользователя.Для реализации этого метода в скрипте автоподстановки мы можем использовать следующий подход:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ЗадачиИсполнителя.Исполнитель КАК ФактическийИсполнитель
|ИЗ
| Задача.ЗадачаИсполнителя КАК ЗадачиИсполнителя
|ГДЕ
| ЗадачиИсполнителя.Предметы.Предмет = &Источник
| И ЗадачиИсполнителя.Выполнена = ИСТИНА
| И ЗадачиИсполнителя.Наименование ПОДОБНО ""%Согласование с ПЭО%""
|УПОРЯДОЧИТЬ ПО
| ЗадачиИсполнителя.ДатаЗавершения УБЫВ";
Запрос.УстановитьПараметр("Источник", Источник);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
Результат = Выборка.ФактическийИсполнитель;
КонецЕсли;
Этот метод считается более "чистым", так как он опирается на историю выполнения задач, а не на состояние справочников, которые могут меняться вручную.
В редакции 3.0 архитектура процессов существенно изменилась. Теперь мы работаем не с отдельными бизнес-процессами, а с единым процессом обработки, разделенным на действия. Выясним причину, по которой старые запросы могут не сработать: данные об участниках теперь хранятся в других таблицах.
Для версии 3.0 рекомендуется использовать программный интерфейс (API) системы. Например, можно обратиться к модулю РаботаСДействиямиОбъект или анализировать регистр сведений ИсполнителиЗадач. В скрипте автоподстановки для 3.0 мы можем получить исполнителя конкретного действия, обратившись к коллекции Действия текущего процесса обработки документа.
Проанализируем последовательность действий администратора или разработчика для настройки этой автоматизации:
Результат присваивается значение.Таким образом, мы исключаем человеческий фактор и необходимость ручного выбора сотрудника на каждом этапе. Система сама "вспомнит", кто работал с документом ранее, и направит задачу по адресу.