В статье приводится несколько примеров настройки бизнес-процессов с использованием системы "БИП: Бизнес-Процессы". Все действия выполняются без использования режима Конфигуратор. Только пользовательский режим. Примеры приводятся в конфигурации «1С:Управление Торговлей», ред. 11.4 с подключенной подсистемой "БИП: Бизнес-Процессы".

В этой статье приводятся примеры использования системы «БИП: Бизнес-Процессы».

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

Подсистема подключена к типовой конфигурации «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. Создание и согласование заказа поставщику (Вариант №2)

Начиная с версии 1.0.2.0, в программе появилась возможность указывать отсроченный запуск по условию. Это означает, что шаг, для которого настроен такой вид отложенного запуска, будет запускаться только при выполнении определенного условия.

В данном случае, сценарий будет состоять из 3 шагов: Старт, Обработка и Завершение.

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

Процесс не завершается до тех пор, пока в заказе поставщику не будет установлен статус Согласован.

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

На карте активного процесса этап Завершение будет отображаться как отложенный шаг с пиктограммой , указывающей на запуск по условию.

Наверх

Пример №15. Обработка файлов в каталоге

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

Для решения задачи создаётся сценарий, состоящий из 1 шага – Действия.

Сценарий запускается по расписанию(_Регламент) И при выполнении указанного условия(_Условие):

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

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

Алгоритм проверки сохранен в справочник Алгоритмы.

После запуска сценария, по расписанию и при выполнении условия наличия файлов в папке, для пользователя будет создана задача.

В задаче будет указан порядок действий и будет размещена ссылка на каталог для быстрого доступа к файлам.

После завершения задачи, процесс будет завершен и сценарий вновь запустится по расписанию и при выполнении указанного условия.

В комплект поставки входит папка \ExtAlg, содержащая различные алгоритмы.

Эти алгоритмы могут быть загружены в программу кнопкой в списке справочника Алгоритмы.

Наверх

Пример №16. Использование с системой взаимодействия

*Для работы со штатной системой взаимодействия, а также к электронной почтой, предназначена подсистема «Сигнал». В данной главе приводится расширенный пример работы с системой взаимодействия. Наверх

Работа с системой взаимодействия организуется штатными средствами технологической платформы «1С:Предприятие 8.3» и программы «1С:Сервер взаимодействия». Вопросы установки и настройки сервера взаимодействия и регистрации информационной базы здесь не рассматриваются.

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

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

Для этих целей была добавлена константа Использовать обсуждения в задачах.

Использование константы ограничивается следующим программный кодом:

Задача: Входящие письма по браку должны отражаться в общем обсуждении «Всё по браку».

Для решения этой задачи добавим сценарий с автозапуском по событию. Событие - при создании нового документа Электронное письмо входящее с дополнительным отбором.

*Для примера, дополнительный отбор настроен предельно просто. В действительности, фильтр писем по определённой тематике - отдельная задача, которая не решается так «в лоб», как в этом примере. Но для демонстрации работы сценария, такого отбора будет достаточно.

В алгоритме шага Обработка добавим программный код создания сообщения в заданном обсуждении.

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

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

Указанные в сценарии получатели в правом нижнем углу и в списке оповещений увидят уведомление о новом сообщении:

В общем обсуждении появится новое сообщение со ссылкой на входящее письмо:

Конечно, сообщение в таком виде - это базовый вариант сообщения.

На практике оно может выглядеть более содержательно. Например, вот так:

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

Но, это уже отдаётся на усмотрение конкретного разработчика и его Заказчиков.

Наверх

Все приведенные примеры были реализованы в пользовательском режиме.

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

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

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

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

А возможность экспорта/импорта готовых сценариев и алгоритмов позволяет применять настроенные и проверенные сценарии в разных конфигурациях без их сравнения, объединения и «тонких настроек» в Конфигураторе, часто требующихся, чтобы внедрить и заставить работать новый функционал одной конфигурации в другой.