← На главную

При настройке и использовании бизнес-процессов согласования в 1С:Документооборот часто возникает вопрос о назначении реквизитов Исполнитель и УстановилРезультат в справочнике ВизыСогласования. Разберем ситуацию подробно: на первый взгляд кажется, что первый реквизит предназначен для пользователя, которому задача назначена, а второй — для того, кто фактически нажал кнопку согласования. Однако на практике их поведение сильно зависит от системных настроек, что иногда приводит к непредвиденным ошибкам при делегировании прав. Давайте проанализируем эту механику и найдем оптимальные пути решения возникающих проблем.

Влияние настройки «Фактический исполнитель задач»

Поведение системы во многом определяется константой «Фактический исполнитель задач». Эта настройка имеет три возможных значения:

1. Исполнитель, указанный в задаче — независимо от того, кто нажал кнопку выполнения, в истории и визах останется тот, кому задача была адресована изначально.
2. Текущий пользователь — исполнителем будет записан тот человек, который фактически вошел в систему под своей учетной записью и выполнил задачу.
3. Выбирать при выполнении — система предложит пользователю самостоятельно указать, от чьего имени выполняется действие.

Рассмотрим ситуацию: Петров выполняет задачу за Иванова на правах делегирования, а в базе установлена настройка «Текущий пользователь». В результате в карточке визы и в реквизит Исполнитель, и в реквизит УстановилРезультат запишется Петров.

Суть проблемы: ошибка «Виза для исполнителя уже существует»

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

В бизнес-процессе «Согласование» участвуют два конкретных сотрудника — Иванов и Петров. Иванов уходит в отпуск и делегирует свои права Петрову. Петров заходит в систему и сначала выполняет задачу, пришедшую Иванову. Поскольку настройка требует фиксировать текущего пользователя, система создает визу, где Исполнитель = Петров.

Затем по маршруту приходит очередь собственной задачи Петрова. Он пытается ее согласовать, но получает системное сообщение: «При создании визы согласования произошла ошибка. Виза для исполнителя Петров уже существует в документе». Процесс останавливается. Это происходит из-за жесткого ограничения конфигурации: в одном документе не может быть двух активных (действующих) виз, принадлежащих одному и тому же физическому пользователю (элементу справочника Пользователи).

Для чего разработчики разделили реквизиты?

Зачем вообще нужен реквизит УстановилРезультат, если он так часто дублирует исполнителя? Выясним основные причины такой архитектуры:

1. Ручной ввод виз делопроизводителем: Часто руководитель не работает в программе напрямую, а передает бумажный документ секретарю. Секретарь вносит результат в систему вручную. В этом случае Исполнитель — это руководитель (он принял решение), а УстановилРезультат — секретарь (он физически занес данные). Это позволяет избежать сомнений в подлинности визы.
2. Юридическая значимость и аудит: При разборе спорных ситуаций (например, при аудиторской проверке) важно четко разграничивать, кто по регламенту должен был принять решение (особенно при ролевой адресации), и чья электронная подпись или учетная запись фактически была применена для подтверждения.

Как решить проблему дублирования виз

Посмотрим на практические способы преодоления коллизии с визами при делегировании. Мы можем пойти несколькими путями: от изменения методологии до программной доработки.

1. Переход на ролевую адресацию (Рекомендованный метод)

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

2. Ручной перенос виз в историю

Если изменить маршруты на ролевые прямо сейчас невозможно, существует пользовательский обходной путь. Чтобы Петров смог наложить свою вторую визу, первую (уже закрытую за Иванова) визу нужно вручную переместить в историю. Для этого активная запись удаляется из текущих виз документа (переводится в исторические данные). После очистки текущего пула виз система позволит успешно закрыть вторую задачу.

3. Программная доработка (Автоматизация)

Если подобные ситуации возникают регулярно, можно прибегнуть к небольшой модификации конфигурации. Суть доработки заключается во вмешательстве в процедуру перед записью новой визы или перед выполнением задачи. Алгоритм должен проверять: если для текущего пользователя в документе уже есть активная виза (созданная, например, по делегированию), программный код должен автоматически переносить старую визу в регистр или табличную часть истории виз, освобождая место для новой. Это полностью устраняет фактическую остановку бизнес-процессов на предприятии.