Схема бизнес процесса 1с пример

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

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

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

Какой инструментарий предусмотрен в графическом редакторе?

Элементы схемы бизнес-процесса

Условные обозначения карты маршрута в нотации 1С.

Элементы называются точками:

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

Приёмы алгоритмизации процессов

Ветвление с условием

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

Например, в случае создания бизнес-процесса обработки жалоб: если клиент доволен решением проблемы, то завершение процесса, если нет — возврат к этапу рассмотрения жалобы .

Выбор вариантов процесса

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

Например, процесс согласования документа, возможны варианты:

• согласован
• на доработку
• отказ

Параллельные бизнес-процессы

Удобный инструмент, если в бизнес-процессе предусмотрены параллельные ветви .

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

Польза знаний алгоритмизации

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

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

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

Полезно решать задачи и разбирать типовые бизнес-процессы. Например, такие и более сложные:

Источник: dzen.ru

Схема бизнес процесса 1с пример

РосПатент: №2022667718 от 23.09.22
Единый реестр: №15564 от 18.11.22

5 сертификатов «1С:Совместимо!»

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

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

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

Подсистема подключена к типовой конфигурации «1С:Управление Торговлей», ред. 11.4.

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

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

• Простой маршрут согласования
• Периодическое действие по условию
• Создание и согласование заказа поставщику
• Создание и согласование заказа поставщику (Вариант №2)
• Обработка файлов в каталоге
• Использование с системой взаимодействия

Задача: Сценарий маршрута согласования. Если сумма заказа клиента превышает 10000, то перейти к действию №1, иначе к действию №2.

После записи заказа клиента создаётся новый Процесс и Задача по нему.

В качестве Источника события указан записанный ранее заказ клиента.

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

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

Процессы сформировались «одновременно» после очередного выполнения регламентного задания обработки стека событий.

Задача: Каждый час присылать на почту уведомление, пока статус задачи = В работе.

Решение: Добавить сценарий с автозапуском по расписанию каждый час.

В сценарии 1 шаг – автоматическая обработка. В обработке указать готовый алгоритм, который получает список задач со статусом «В работе» и по каждой задаче формирует уведомление на электронную почту. Или формирует письма с группировкой по получателям – в зависимости от деталей первоначальной постановки задачи.

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

2-ой вариант («альтернативный» для демонстрации возможности повторного выполнения этапов сценария): создать сценарий с ручным запуском.

1-ый шаг – проверка условия. Выполняется через 1 час после запуска. В условии выполняется программный код по проверке наличия задач в работе. Если проверка условия возвращает значение Истина, то выполняется следующий шаг Обработка, в котором происходит формирование электронных писем. После чего сценарий возвращается (через 1 час снова к проверке условия).

В итоге, получается цикл Пока… с выполнением проверки каждый час.

Алгоритмы формирования писем потребуется написать самостоятельно или взять готовые.

1. При записи заказа клиента, запускается новый бизнес-процесс;

2. Выполняется шаг обработка «Создание заказа поставщику», которое через произвольный алгоритм создает заказ поставщику.

3. На следующем этапе нужно проверять (получается, с определенной периодичностью) статус созданного заказа поставщику, и как только статус станет «Согласовано» — закрыть бизнес-процесс (далее БП)

Если статус не «Согласовано» БП не должен завершаться.

Возможно, третий шаг можно по-другому обыграть в вашем решении.

Но суть одна — нужно создать объект на первом этапе, а на втором этапе проверять значение его реквизита (с периодичностью, например 5 минут), и от этого значения дальше будет выстраиваться логика БП.

Для шага вида Условие указан запуск « через 5 мин. ».

* Для примера, сценарий будет запускаться при записи элемента справочника Алгоритмы (на логику примера это не повлияет). Это может быть любой другой справочник или документ.

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

Логика следующая: должен выполниться некий программный код, в результате которого мы получим ссылку на новый документ Заказ поставщику. ту ссылку надо сохранить в текущем процессе. Для сохранения различных данных в процессе выполнения сценария предусмотрена табличная часть Объекты с реквизитом Объект (Тип ЛюбаяСсылка , Булево , Строка , Дата , Число ). При записи можно указать ОбменДанными . Загрузка = Истина , чтобы не выполнялся программный код, проверяющий состояния процессов и выполняющий дополнительные процедуры, которые в данном случае не имеют смысла.

В настройках шага Условие указано следующее условие:

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

Для примера же, условие выполняется, если в табличной части Объекты добавлено 2 строки.

Т.к. при невыполнении условия ( _Результат = Ложь ), процесс возвращается в шаг Обработка, то в обработке следует добавить дополнительную проверку, чтобы заказ не создался повторно.

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

Проще, всё-таки, в шаге Обработка добавить условие Если НЕ _Процесс . Объекты . Количество () Тогда …

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

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

*Шаг можно запустить и принудительно, не дожидаясь наступления настроенного времени.

Процесс завершится, когда цикл Обработка–Условие выполнится 2 раза.

Условие завершения зависит от программного кода, который настроен в шаге вида Условие.

В карточке завершенного процесса в поле Объект указан источник события – элемент справочника «Алгоритмы». В табличной части Объекты указаны объекты, добавленные программно в процессе выполнения сценария.

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

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

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

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

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

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

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

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

Наверх

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: bip.one