Как создать бизнес-процесс в 1С: пошаговое руководство

Бизнес-процессы в 1С — это механизм платформы, который позволяет формализовать последовательность действий сотрудников: согласование заявки, обработку заказа, приём сотрудника на работу, выдачу доступа. Вместо устных договорённостей система сама формирует задачи нужным исполнителям, контролирует сроки и ведёт историю прохождения каждого этапа. Создать бизнес-процесс можно в конфигураторе через объект метаданных «Бизнес-процессы», а в типовых решениях на базе БСП — частично и в пользовательском режиме.

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

Что понадобится перед началом работы

Для создания бизнес-процесса нужны права на конфигуратор и понимание структуры прикладного решения. Если база находится на поддержке типовой конфигурации, любые изменения снимут её с полной поддержки — обновления придётся накладывать с сопоставлением вручную. Поэтому первое действие — снять копию базы и разрабатывать на ней, а не на рабочем контуре.

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

Создание объекта «Бизнес-процесс» в конфигураторе

Откройте конфигуратор, в дереве конфигурации найдите ветку «Бизнес-процессы» и добавьте новый объект. Задайте имя и синоним, например «СогласованиеЗаявкиНаЗакупку». На закладке «Данные» добавьте реквизиты процесса — это поля, которые будут хранить контекст конкретного экземпляра: ссылку на документ-основание, инициатора, сумму, комментарий, результат согласования.

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

На закладке «Нумерация» и «Длина номера» обычно оставляют значения по умолчанию. Полезно сразу настроить представление процесса через обработчик «ОбработкаПолученияПолейПредставления» или просто добавить понятный синоним, чтобы пользователи видели в списках читаемые названия, а не технические номера.

Построение карты маршрута

Карта маршрута — визуальная схема процесса, которая редактируется на закладке «Карта маршрута» объекта бизнес-процесса. Из панели элементов перетаскиваются точки: старт, действие, условие, выбор варианта, разделение, слияние, вложенный бизнес-процесс, обработка и завершение. Точки соединяются стрелками переходов.

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

1. 1
   Добавьте точку старта и точку завершения — они обязательны в любой карте
2. 2
   Разместите точки действий по числу этапов согласования и подпишите их понятными именами
3. 3
   Добавьте точки условий там, где маршрут зависит от данных процесса (сумма, подразделение, тип заявки)
4. 4
   Соедините точки стрелками и проверьте, что из каждой точки есть путь до завершения
5. 5
   Откройте свойства каждой точки действия и укажите, какая задача формируется и кому она адресована

Частая проблема — «висячие» ветки, из которых нет перехода к завершению. Платформа не всегда явно ругается на такую схему, но экземпляр процесса зависнет навсегда. После построения карты мысленно пройдите по ней от старта до конца по каждой ветке условий.

Настройка задач и адресации исполнителей

Бизнес-процесс сам по себе не создаёт задач — для этого нужен связанный объект «Задача». В типовых конфигурациях обычно уже есть задача «ЗадачаИсполнителя», в собственной разработке её нужно создать и указать в свойстве бизнес-процесса в поле «Задача». Именно задачи видит пользователь в своём списке «Мои задачи».

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

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

Обработчики событий и программная логика

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

Для точки условия результат вычисления возвращается через параметр обработчика. Пример логики: если сумма заявки больше порога — маршрут идёт по ветке дополнительного согласования, иначе сразу к завершению. Порог лучше хранить в константе или регистре сведений, а не зашивать в код, чтобы его мог менять администратор без участия разработчика.

Процедура СогласованиеРуководителемПриВыполненииЗадачи(ТочкаМаршрута, Задача, Отказ)
	Если Не Согласовано Тогда
		Возврат; // маршрут пойдёт по ветке отклонения
	КонецЕсли;
КонецПроцедуры

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

Запуск процесса: вручную и автоматически

Самый простой способ запуска — команда в форме документа. Добавьте в форму документа кнопку «Запустить согласование», в обработчике которой создаётся новый бизнес-процесс, заполняются реквизиты (ссылка на документ, инициатор), процесс записывается и вызывается метод Старт(). После старта объект перезаписывается.

Автоматический запуск делается через подписку на событие «ПриЗаписи» документа. В обработчике проверяйте условия: документ проведён, для него ещё не запущен процесс, вид операции подходит. Без проверки на существующий экземпляр каждая перезапись документа будет плодить новые процессы — это одна из самых частых ошибок.

Тестирование и проверка результата

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

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

Типичные ошибки и ограничения

Учитывайте и ограничения механизма: бизнес-процессы платформы не являются полноценным BPMN-движком. Сложные сценарии с таймерами, эскалациями и массовыми параллельными согласованиями требуют дополнительной разработки: регламентных заданий для контроля просрочки, регистров для хранения состояния, отдельных механизмов делегирования. Если требования близки к классическому BPM, оцените, не проще ли использовать специализированную конфигурацию или внешнюю систему с интеграцией.

Частые вопросы