1С8: Бизнес-процессы для чайников

Когда я столкнулся с бизнес-процессами, они показались мне таким же темным лесом, как в своё время регистры расчета. Я пустыми глазами смотрел на демо-пример от 1С, читал статьи в Интернете, и ничего не понимал.
Однако в бизнес-процессах нет ничего сложного. Это своё кристально чистое видение я попытаюсь передать и вам.

Когда я столкнулся с бизнес-процессами, они показались мне таким же темным лесом, как в своё время регистры расчета. Я пустыми глазами смотрел на демо-пример от 1С, читал статьи в Интернете, и ничего не понимал.

Однако в бизнес-процессах нет ничего сложного. Это своё кристально чистое видение я попытаюсь передать и вам.

Уясните сразу, что бизнес-процессы – это всего лишь два новых объекта в 1С 80: бизнес-процессы и задачи. Причем задачи можно использовать самостоятельно и без знания бизнес-процессов. Их можно трактовать, как список задач для текущего пользователя.

По сути, бизнес-процессы – это управление задачами. Т.е. у пользователя есть задачи, он их выполняет, при их выполнении возникают новые задачи.

Бизнес-процесс рисуется в конфигураторе как блок-схема. В этой блок-схеме есть блоки начала и конца алгоритма, блоки выполнения (прямоугольные) и блоки условий. Чтобы бизнес-процесс мог стартовать, у него должна быть стартовая точка (одна или несколько).

Бизнес-процесс может находиться в одной или сразу нескольких точках (при параллельном выполнении).

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

Вы видите, что задачи порождаются при выполнении бизнес-процессов. Однако они могут использоваться и без них, например, создаваться программно или вручную. Они напоминают задачи MS Outlook.

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

Можно назначить задачу целому подразделению и она будет показана у всех пользователей подразделения.

Как соотносятся задачи и бизнес-процессы? Одному виду бизнес процесса соответствует один вид задачи, один вид задач может использоваться в нескольких бизнес процессах. Это странно, потому что в различных точках исполнения одного бизнес процесса мы можем ожидать разные задачи. Например, задача согласования может отличаться от задачи ввода первичных документов. Логичнее было бы привязывать разные задачи к одному бизнес-процессу. В демо-примере все сделано на одном виде задач. Если мы все же хотим использовать разные виды задач, можно использовать вложенные бизнес процессы.

Как видите, все очень просто.

Несколько советов «чайникам»:

· Посмотрите в режиме «Конфигуратор» демо-базу по бизнес-процессам с ИТС - познавательно. В режиме «Предприятие» можете не смотреть, особо ничего не поймете.

· У бизнес-процесс нужно обязательно указать вид задачи – без него конфигурация не сохранится. Сначала может использовать один вид задачи для всех бизнес-процессов.

· Чтобы бизнес-процесс мог стартовать, у него должна быть на карте маршрута хотя бы одна точка входа.

· Каждый блок бизнес-процесса можно назначить исполнителя. Он выбирается из реквизитов адресации задачи, вид которой подвязан к бизнес-процессу. Можно выбирать как исполнителя, пользователя, так и любой другой реквизит адресации, например, назначить задачу подразделению. Можно вообще не использовать системный механизм адресации, и самому определять, какие задачи доступны текущему пользователю. Системный механизм не универсальный, жизнь может продиктовать более сложную схему раздачи задач.

· У задачи нужно не только заполнить реквизиты адресации, но и выбрать основной реквизит адресации, например «Пользователь», выбрать регистр сведений для адресации, переменную сеанса, которая будет соотноситься с основным реквизитом адресации и иметь с ним один тип (!).

· Также не забудьте указать соотношения между реквизитами адресации задачи и измерениями регистра адресации, чтобы связь между задачей и регистром сведений заработала.

· Для контроля списка задач, адресованных текущему пользователю, можете использовать консоль отчетов по таблице всех задач «Задачи» и виртуальной таблице задач текущего (или указанного) пользователя «ЗадачаЗадачиПоИсполнителю».

· Для отладки вы можете отключать признаки того, что бизнес-процесс стартовал или задача выполнена.

С чего начать

На самом деле самая большая сложность – это придумать бизнес-процесс, на котором можно начать изучать механику. Возьмите самый простой бизнес-процесс. Менеджер выписывает расходную накладную. Руководитель отдела должен ее утвердить. После утверждения расходная накладная проводится, и Кладовщик производит отгрузку. Если накладная не утверждена, она помечается на удаление, и бизнес-процесс завершается.

Алгоритм примерно такой:

0: Начало

А: Выполнение: Менеджер оформляет расходную накладную.

Б: Выполнение: Руководитель отдела утверждает накладную.

В: Условие: Если накладная утверждена, тогда Г иначе Д.

Г: Выполнение: Кладовщик выполняет отгрузку. Переход на Е.

Д: Конец: Завершение бизнес-процесса в статусе «Отмена».

Е: Конец: Нормальное завершение бизнес-процесса.

Флажок «Утверждена» можно вносить или в расходную накладную или в сам бизнес-процесс, как реквизит.

Что нужно проконтролировать:

· Когда вы запускаете бизнес-процесс, создаются задачи.

· Когда вы выполняете задачи, бизнес-процесс продвигается по карте маршрута (для этого нужно в форму бизнес-процесса вывести карту маршрута).

· Задачи появляются только у тех пользователей, которым они адресованы (вот здесь мне пришлось попотеть).