Всем здравствуйте!
В этой статье приводятся примеры использования системы 
"БИП: Бизнес-Процессы".
Примеры даны без какой-то классификации или специального отбора - просто несколько разноплановых примеров использования системы "БИП: Бизнес-Процессы" для решения возможных учётных задач.
Подсистема подключена к типовой конфигурации "1С: Управление Торговлей", ред. 11.4.
Для каждого примера дана "постановка задачи" в той форме, в которой она была озвучена реальными пользователями, для которых изначально давались пояснения по каждому из примеров.
Т.к. примеры приводятся без какой-либо классификации или логики следования, то ниже приводится список примеров для более удобной ориентации по ним.
Оглавление
-
Простой маршрут согласования
-
Периодическое действие по условию
-
Создание и согласование заказа поставщику
-
Создание и согласование заказа поставщику (Вариант №2)
-
Обработка файлов в каталоге
-
Использование с системой взаимодействия
Пример №21
Задача: Сценарий маршрута согласования. Если сумма заказа клиента превышает 10000, то перейти к действию №1, иначе к действию №2.
После записи заказа клиента создаётся новый Процесс и Задача по нему.
В качестве Источника события указан записанный ранее заказ клиента.
При необходимости, можно использовать настройку Использовать стек событий. В этом случае, процессы будут формироваться пакетно раз в 2 минуты, а не после каждого возникновения событий автозапуска.
На примере ниже было проведено 4 документа с промежутками между записью.
Процессы сформировались «одновременно» после очередного выполнения регламентного задания обработки стека событий.
Пример №22
Задача: Каждый час присылать на почту уведомление, пока статус задачи = В работе.
Правильный способ: Добавить сценарий с автозапуском по расписанию каждый час.
В сценарии 1 шаг – автоматическая обработка. В обработке указать готовый алгоритм, который получает список задач со статусом «В работе» и по каждой задаче формирует уведомление на электронную почту. Или формирует письма с группировкой по получателям – в зависимости от деталей первоначальной постановки задачи.
В данном случае, сценарий ничем не отличается от обычного регламентного задания – запускается по расписанию и выполняет указанный алгоритм.
2-ой вариант («альтернативный» для демонстрации возможности повторного выполнения этапов сценария): создать сценарий с ручным запуском.
1-ый шаг – проверка условия. Выполняется через 1 час после запуска. В условии выполняется программный код по проверке наличия задач в работе. Если проверка условия возвращает значение Истина, то выполняется следующий шаг Обработка, в котором происходит формирование электронных писем. После чего сценарий возвращается (через 1 час снова к проверке условия).
В итоге, получается цикл Пока… с выполнением проверки каждый час.
Алгоритмы формирования писем потребуется написать самостоятельно или взять готовые.
Пример №14
Задача:
1. При записи заказа клиента, запускается новый бизнес-процесс;
2. Выполняется шаг обработка "Создание заказа поставщику", которое через произвольный алгоритм создает заказ поставщику.
3. На следующем этапе нужно проверять (получается, с определенной периодичностью) статус созданного заказа поставщику, и как только статус станет "Согласовано" - закрыть БП
Если статус не "Согласовано" БП не должен завершаться.
Возможно, третий шаг можно по другому обыграть в вашем решении.
Но суть одна - нужно создать объект на первом этапе, а на втором этапе проверять значение его реквизита (с периодичностью, например 5 минут), и от этого значения дальше будет выстраиваться логика БП.
Для шага вида Условие указан запуск «через 5 мин.».
*Для примера, сценарий будет запускаться при записи элемента справочника Алгоритмы (на логику примера это не повлияет). Это может быть любой другой справочник или документ.
В настройках шага Обработка указан программный код для выполнения. Можно выбрать готовый алгоритм из справочника или написать код вручную, как на примере ниже.
Логика следующая: должен выполниться некий программный код, в результате которого мы получим ссылку на новый документ Заказ поставщику. Эту ссылку надо сохранить в текущем процессе. Для сохранения различных данных в процессе выполнения сценария предусмотрена табличная часть Объекты с реквизитом Объект (Тип ЛюбаяСсылка, Булево, Строка, Дата, Число). При записи можно указать ОбменДанными.Загрузка = Истина, чтобы не выполнялся программный код, проверяющий состояния процессов и выполняющий дополнительные процедуры, которые в данном случае не имеют смысла.
В настройках шага Условие указано следующее условие:
*Закомментированный код проверяет статус заказа поставщику в табличной части Объекты (для упрощения, ссылка на заказ поставщику получена напрямую по индексу).
Для примера же, условие выполняется, если в табличной части Объекты добавлено 2 строки.
Т.к. при невыполнении условия (_Результат = Ложь), процесс возвращается в шаг Обработка, то в обработке следует добавить дополнительную проверку, чтобы заказ не создался повторно.
Или, между обработкой и условием можно добавить какой-то промежуточный шаг вида Обработка с незначимым программным кодом и возвращаться при невыполнении условия в этот шаг.
Проще, всё-таки, в шаге Обработка добавить условие Если НЕ _Процесс.Объекты.Количество() Тогда…
Сценарий запускается при записи любого элемента справочника Алгоритмы (т.к. не был настроен дополнительный фильтр автособытий).
В первую очередь, выполняется шаг Обработка и процесс ожидает, когда наступит время проверить условие.
*Шаг можно запустить и принудительно, не дожидаясь наступления настроенного времени.
Процесс завершится, когда цикл Обработка–Условие выполнится 2 раза.
Условие завершения зависит от программного кода, который настроен в шаге вида Условие (показан выше).
В карточке завершенного процесса в поле Объект указан источник события – элемент справочника «Алгоритмы». В табличной части Объекты указаны объекты, добавленные программно в процессе выполнения сценария.
Таким образом, табличная часть Объекты используется как буфер для хранения данных, которые могут использоваться в процессе выполнения сценария.
*Конечно, использование табличной части Объекты не обязательно. Найти созданный заказ поставщика можно и через поле Объект, используя типовой критерий отбора или какие-то другие реквизиты, или выполнить запрос и по известному заказу клиента найти созданный заказ поставщику. Но в данном случае, мы имеем возможность сохранить ссылку на созданный документ и использовать её в течении всего процесса.
Пример №14, начиная с версии 1.0.2.0
Начиная с версии 1.0.2.0, в программе появилась возможность указывать отсроченный запуск по условию. Это означает, что шаг, для которого настроен такой вид отложенного запуска, будет запускаться только при выполнении определенного условия.
В данном случае, сценарий будет состоять из 3 шагов: Старт, Обработка и Завершение.
При записи заказа клиента, запускается сценарий, в котором выполняется обработка, формирующая заказ поставщику. Созданный заказ поставщику записываться в новый процесс. Этот этап аналогичен предыдущему примеру.
Процесс не завершается до тех пор, пока в заказе поставщику не будет установлен статус Согласован.
*Для упрощения примера, получение объекта из строки табличной части производится по индексу без проверки возможных исключений (количество строк и тип значения указанного в строке объекта).
На карте активного процесса этап Завершение будет отображаться как отложенный шаг с пиктограммой 
, указывающей на запуск по условию.
Пример №15
Задача: В отдельную папку менеджеры складывают графические изображения – сканы подписанных договоров. Требуется создавать задачу для ответственного пользователя, который будет проверять сканы и прикреплять их к договорам в программе.
Для решения задачи создаётся сценарий, состоящий из 1 шага – Действия.
Сценарий запускается по расписанию(_Регламент) И при выполнении указанного условия(_Условие):
Если в указанном каталоге есть файлы, то требуется создать задачу для пользователя по обработке этих файлов.
Проверка файлов осуществляется 1 раз в день, при этом задача ставится, когда в папке будет находиться количество файлов, больше указанного. Это сделано для того, чтобы не создавать каждый день пользователю задачу, если в папке мало файлов для обработки.
Алгоритм проверки сохранен в справочник Алгоритмы.
После запуска сценария, по расписанию и при выполнении условия наличия файлов в папке, для пользователя будет создана задача.
В задаче будет указан порядок действий и будет размещена ссылка на каталог для быстрого доступа к файлам.
После завершения задачи, процесс будет завершен и сценарий вновь запустится по расписанию и при выполнении указанного условия.
В комплект поставки входит папка \ExtAlg, содержащая различные алгоритмы.
Эти алгоритмы могут быть загружены в программу кнопкой 
в списке справочника Алгоритмы.
Пример №16
*Для работы со штатной системой взаимодействия, а также к электронной почтой, предназначена подсистема «Сигнал». В данной главе приводится расширенный пример работы с системой взаимодействия.
Работа с системой взаимодействия организуется штатными средствами технологической платформы "1С: Предприятие 8.3" и программы "1С: Сервер взаимодействия". Вопросы установки и настройки сервера взаимодействия и регистрации информационной базы здесь не рассматриваются.
На скриншоте ниже приведен пример того, как может выглядеть контекстное обсуждение по конкретной задаче.
Использование контекстных обсуждений имеет определенную специфику - видимость кнопки 
зависит от режима открытия окна формы.
Для этих целей была добавлена константа Использовать обсуждения в задачах.
Использование константы ограничивается следующим программный кодом:
Задача: Входящие письма по браку должны отражаться в общем обсуждении "Всё по браку".
Для решения этой задачи добавим сценарий с автозапуском по событию. Событие - при создании нового документа Электронное письмо входящее с дополнительным отбором.
*Для примера, дополнительный отбор настроен предельно просто. В действительности, фильтр писем по определённой тематике - отдельная задача, которая не решается так "в лоб", как в этом примере. Но для демонстрации работы сценария, такого отбора будет достаточно.
В алгоритме шага Обработка добавим программный код создания сообщения в заданном обсуждении.
*...опять же, для упрощения примера, в качестве получателя сообщения указан 1 пользователь. Массив получателей может быть каким угодно.
При появлении в базе входящего электронного письма, удовлетворяющего условиям отбора автособытия, будет выполнен указанный программный код.
Указанные в сценарии получатели в правом нижнем углу и в списке оповещений увидят уведомление о новом сообщении:
В общем обсуждении появится новое сообщение со ссылкой на входящее письмо:
Конечно, сообщение в таком виде - это базовый вариант сообщения.
На практике он может выглядеть более содержательно. Например, вот так:
*А учитывая, что при создании сообщений мы можем добавлять вложения, управлять списком получателей – инструмент получается, во многих случаях, более чем универсальный и гибкий.
Но, это уже отдаётся на усмотрение конкретного разработчика и его Заказчиков.
Все приведенные примеры были реализованы в пользовательском режиме.
Конфигуратор для настройки логики поведения программы не требовался ни разу. *Его использование может потребоваться только для удобства написания и проверки больших алгоритмов, которые позже будут указываться в сценариях.
Такой подход к настройке логики поведения системы в зависимости от различных ситуаций, событий, входных условий позволяет не только сократить время на разработку каких-то новых механизмов, но и позволяет повысить надежность решения за счёт применения единого универсального механизма, который берёт на себя обработку логики сценариев, и который будет одинаково работать при подключении к различным конфигурациям.
Разработчику не требуется создавать новые процедуры и функции для нового функционала, добавлять новые регламентные задания в конфигурацию, приводить всё это в соответствие и, многократно меняя программный код, исправляя и дополняя логику нового механизма, выгонять пользователей из баз для обновлений или запуска внеплановых "технических перерывов", чтобы исправить последствия внедрения нового кода.
Для того, чтобы протестировать какую-то новую цепочку взаимодействий сотрудников, какой-то новый механизм формирования, классификации и обработки данных, не требуется вносить изменения в программу, не требуется многократно обновлять конфигурацию, чтобы добиться от системы нужного поведения. Всё это можно настраивать, тестировать и вводить в эксплуатацию непосредственно в пользовательском режиме.
А возможность экспорта/импорта готовых сценариев и алгоритмов позволяет применять настроенные и проверенные сценарии в разных конфигурациях без их сравнения, объединения и "тонких настроек" в Конфигураторе, часто требующихся, чтобы внедрить и заставить работать новый функционал одной конфигурации в другой.
