Всем здравствуйте!
Это продолжение предыдущих частей Часть №1, Часть №2, Часть №3, Часть №4, Часть №5 и Часть №6, в которых речь шла о различных вариантах и аспектах использования системы 
«БИП: Бизнес-Процессы».
- Часть №1: «БИП: Бизнес-Процессы». Примеры использования. Часть №1.
- Часть №2: «БИП: Бизнес-Процессы». Примеры использования. Часть №2.
- Часть №3: «БИП: Бизнес-Процессы». Примеры использования. Часть №3. Права и связи.
- Часть №4: «БИП: Бизнес-Процессы». Примеры использования. Часть №4. Графика.
- Часть №5: «БИП: Бизнес-Процессы». Примеры использования. Часть №5. Система оповещений.
- Часть №6: «БИП: Бизнес-Процессы». Интеграция с Telegram и Конструктор чат-ботов.
Программный продукт 
«БИП: Бизнес-Процессы» предназначен для настройки произвольных бизнес-процессов в пользовательском режиме в любых конфигурациях 1С, работающих на технологической платформе «1С:Предприятие 8.3» в режиме управляемого приложения. Продукт может использоваться как отдельная конфигурация для моделирования бизнес-процессов, как дополнение для встраивания в существующие конфигурации и как расширение. Каждый вариант сертифицирован и имеет официальный статус «1С:Совместимо!».
Программный продукт предлагается в 2 вариантах:
- Основная поставка
«БИП: Бизнес-Процессы»; - Базовая версия
Расширение для настройки бизнес-процессов «Зодиак».
Сценарий «Обработка интернет-заказа клиента»
Произвольно подготовленный неформализованный сценарий:
Задача
Реализовать сценарий в системе «БИП: Бизнес-Процессы».
Вместо предисловия
В статье будет показан пример настройки сценария. Т.к. инструмент настройки универсален, варианты реализации сценария могут варьироваться в зависимости от требований конкретной ситуации и/или прочих неуточненных деталей.
Пример состоит из 2 частей:
- 1-ая часть – один из возможных вариантов реализации сценария.
- 2-ая часть – пример оптимизации примера из 1-ой части в целях минимизации участия пользователей в процессе исполнения сценария.
Комментарии, нюансы и подробности реализации будут даны только по тем моментам, которые разработчик посчитал нужным уточнить. Прочие моменты, которые могут вызвать вопросы, следует обсудить индивидуально или рассмотреть их самостоятельно, используя документацию к программе.
Часть 1: Настройка сценария
Сценарий
Графическая схема сценария показана на изображении ниже.
Рисунок 1: Графическая схема сценария
Запуск сценария
Запуск сценария: Автоматический по событию.
Событие запуска: Создание нового документа вида «Заказ клиента», у которого в комментарии присутствует строка «VT-» (клиентом не уточняется, возможно, это префикс номера интернет-заказа, который сохраняется в комментарии при загрузке заказов с сайта).
Рисунок 2: Настройка автоматического запуска сценария по событию
Для каждого нового интернет-заказа будет запускаться свой экземпляр процесса по данному сценарию.
Описание шагов сценария
Здесь будет дано описание некоторых нюансов, связанных с настройкой данного сценария.
1-ый шаг сценария, шаг, который будет выполнен сразу после запуска сценария (т.е. после создания нового заказа клиента), это шаг проверки – указан ли в новом заказе менеджер.
В зависимости от того, указан менеджер или нет, процесс по сценарию пойдет в различных направлениях.
Проверка на данном шаге будет происходить автоматически без участия пользователей. Для этого в настройках шага сценария следует указать настройку проверки условия.
Рисунок 3: 1-ый шаг сценария – проверка условия
Рисунок 4: Настройка проверки условия
Условие проверки настраивается как Отбор (подобно отборам в отчётах 1С). Также, вместо отбора можно использовать «скрипт» - программный код проверки, как показано на изображении ниже.
Рисунок 5: Использование программного кода для проверки условий.
Как работает данная проверка: в объекте процесса – в заказе клиента, по которому запущен сценарий, проверяется поле «Менеджер». Если поле заполнено, то условие выполнено и процесс переходит на шаг «Подтвердить/Согласовать заказ». Если условие не выполнено (поле «Менеджер» в заказе не заполнено), процесс переходит на шаг «Назначить менеджера». На этом шаге ответственному пользователю (в данном примере он не указан) будет назначена задача для выполнения.
Для шага «Назначить менеджера» указано дополнительное описание.
Рисунок 6: Дополнительное описание задачи
В настройках шага указано, что для её завершения должно быть заполнено поле «Менеджер» в заказе клиента. Без этого пользователь не сможет перевести задачу в состояние 
Выполнена (соответствующее сообщение об ошибке показано на рисунке Рисунок 8: Сообщение об ошибке выполнения задачи).
Рисунок 7: Настройка выполнения задачи
Рисунок 8: Сообщение об ошибке выполнения задачи
Также, эта настройка позволяет системе завершить задачу автоматически при выполнении данного условия. Т.е. после того, как в заказе будет указан менеджер, задача завершится автоматически и процесс перейдет на следующий шаг сценария.
Форма задачи, которую увидит ответственный пользователь, по данному шагу будет выглядеть, как показано на рисунке ниже.
На форме будет показано Подробное описание и указан Источник события – заказ клиента, по которому выполняется наш сценарий.
Рисунок 9: Форма задачи о заполнении менеджера в заказе клиента
Следующим шагом сценария является шаг «Подтвердить/Согласовать заказ».
Для задачи по этому шагу установлен срок выполнения 2 часа и признак Важности (Рисунок 10: Настройка срока выполнения).
Рисунок 10: Настройка срока выполнения
В качестве исполнителя задачи выбран менеджер, указанный в заказе клиента (Рисунок 11: Выбор исполнителя задачи из списка доступных реквизитов).
Исполнитель задачи может быть определен с помощью произвольного скрипта или выбран из списка доступных реквизитов.
Рисунок 11: Выбор исполнителя задачи из списка доступных реквизитов
В настройках выполнения задачи указано условие, что задачу можно завершить, только если у заказа установлен статус «К выполнению/В резерве» (Рисунок 12: Настройка выполнения задачи и кнопка «Выполнена»).
Дополнительно, там же, указано новое название для кнопки «Выполнена».
Рисунок 12: Настройка выполнения задачи и кнопка «Выполнена»
Форма задачи по данному шагу будет выглядеть, как показано на рисунке Рисунок 13: Форма задачи подтверждения и согласования заказа клиента.
Рисунок 13: Форма задачи подтверждения и согласования заказа клиента
В соответствии с настройками сценария, задача не сможет быть переведена в статус Выполнена, пока в заказе клиента не будет установлен статус «К выполнению/В резерве».
После подтверждения и согласования заказа, процесс перейдет на следующий шаг сценария. На динамической карте процессе мы можем наблюдать текущее состояния сценария. Текущий шаг сценария отмечен значком 
.
Рисунок 14: Текущая карта процесса
В данном случае следующий шаг сценария – это «Проверка наличия товара».
|
Здесь мы рассматриваем вариант проверки наличия товара ответственным пользователем. Во второй части примера рассмотрим настройку автоматической проверки наличия товара. |
Часть сценария по ручной проверке наличия товара по заказу состоит из 2 шагов – задача менеджеру «Проверить наличие товара» и проверка условия «Товар в наличии?». Условие будет проверяться вручную пользователем.
В настройках шага «Проверить наличие товара» включим проверку условия как показано на рисунке Рисунок 15: Настройка проверки наличия товара.
Рисунок 15: Настройка проверки наличия товара
Рисунок 16: Проверка условия в задаче
По сценарию, если пользователь ответит «Да» (товар по заказу в наличии), сценарий перейдет на этап оформления счёта на оплату. Если пользователь ответит «Нет» (товара в наличии нет), следующим шагом сценария будет задача отделу снабжения, который должен будет ответить на вопрос «Будет товар в наличии или нет».
Если товар будет, то сценарий перейдет на шаг «Задержка», в котором указан отложенный запуск через 1 день. После задержки в 1 день сценарий снова перейдет на этап «Проверить наличие товара».
Рисунок 17: Отложенный запуск
Если товара не будет, то сценарий перейдет на шаг «Подтвердить/Согласовать заказ». В данном случае это будет означать, что менеджеру потребуется скорректировать заказ. После чего, шаги сценария проверки наличия товара по заказу будут повторены.
Дополнительно, если снабженец в своей задаче указал Комментарий, то менеджер, которому будет вновь назначена задача «Подвердить/Согласовать заказ», сможет увидеть этот комментарий на форме своей задачи в поле «Комментарий предыдущей задачи».
Рисунок 18: Ввод комментария об отсутствии товара
Рисунок 19: Отображение комментария из предыдущей задачи в текущей задаче
После того, как наличие товара по заказу будет подтверждено, процесс перейдет на следующий шаг сценария – «Сформировать счёт на оплату и отправить по шаблону покупателю».
|
Здесь мы рассматриваем вариант создания и отправки счёта покупателю Во второй части примера рассмотрим настройку автоматического формирования и отправки счёта. |
В настройках действия укажем, что для завершения задачи требуется указать созданный счёт. Это показано на рисунке Рисунок 20: Выбор объекта задачи.
Рисунок 20: Выбор объекта задачи
В ходе процесса работы с интернет-заказом, ответственный пользователь создаст счёт на оплату, отправит его покупателю и укажет его в выполняемой задаче.
После этого процесс перейдет на шаг «Проверка оплаты».
Этот шаг вида 
Выбор варианта запускается отложенно через 3 часа и состоит из 3 вариантов:
- Ожидание оплаты,
- Оплата получена,
- Счёт не оплачен через 3 дня.
Рисунок 21: Выбор варианта «Проверка оплаты»
Для каждого их этих вариантов должно быть задано условие, при котором каждый вариант будет выбран. Для последнего варианта условие можно не указывать, т.к. этот вариант всегда будет выбираться автоматически, если не подошел ни один из предыдущих вариантов.
|
Для упрощения примера предположим, что оплата по счёту подтверждается знаком «+» в комментарии к счёту. Этот плюсик, например, может устанавливать менеджер, который контролирует оплату. Повторим, что такое допущение сделано исключительно для упрощения нашего примера. В реальности информацию об оплате следует получать из соответствующих регистров взаиморасчётов (или по счетам бух. учета при использовании системы в рамках программы «1С: Бухгалтерия Предприятие»). |
Пример проверки условия для варианта «Счёт оплачен» приведен на рисунке Рисунок 22: Проверка условия «Счёт оплачен». Счёт оплачен, если в комментарии есть «+».
Рисунок 22: Проверка условия «Счёт оплачен»
Для варианта «Ожидание оплаты» укажем проверку как на рисунке Рисунок 23: Проверка условия «Ожидание оплаты». Символа «+» в комментарии к счёту нет и 3 дня с момента выставления счёта ещё не прошло.
Рисунок 23: Проверка условия «Ожидание оплаты»
Если ни вариант «Счёт оплачен», ни вариант «Ожидание оплаты» не подошли по результатам проверки, то система автоматически выберет 3-ий вариант «Счёт не оплачен через 3 дня».
Дальнейшее поведение процесса по сценарию будет зависеть от того, будет ли оплачен счёт. Сценарий хорошо виден на графической схеме (Рисунок 1: Графическая схема сценария) и останавливаться на всех возможных вариантах здесь мы больше не будем.
Следующий шаг – подготовка вручную документов для сборки/отгрузки. Это шаг «Подготовить документы для сборки/отгрузки».
Результатом этого шага могут быть заказы на сборку, расходные складские ордера и т.п.
После того, как этот шаг будет выполнен начнется этап «Контроль отгрузки».
Здесь, по аналогии с шагом «Проверка оплаты», для каждого из возможных вариантов развития событий по сценарию требуется указать программный код для проверки каждого из вариантов.
И, в зависимости от ситуации, система будет реализовывать те или иные направления сценария.
На рисунке Рисунок 24: Не взяли заказ в работу через 5 часов приведен пример динамической карты процесса, когда по истечении 5 часов складские документы отгрузки не были взяты в работу.
Рисунок 24: Не взяли заказ в работу через 5 часов.
В данном случае сценарий зациклен и после выполнения кладовщиком задачи по выяснению причины, процесс вернется на этап «Контроль отгрузки».
Периодичность контроля отгрузки может быть указана в настройках запуска шага сценария. Например, проводить контроль отгрузки 1 раз в час.
Рисунок 25: Отложенный запуск этапа «Контроль отгрузки»
Когда контроль отгрузки определит, что товар по заказу отгружен, данный процесс по текущему интернет-заказу будет завершен. На карте процесса текущий результат контроля отгрузки будет отмечен символами «>>>».
Рисунок 26: Товар отгружен, Процесс завершен
Часть 2: Оптимизация
Часть ручных операций, настроенных в сценарии, можно исключить, автоматизировав некоторые шаги сценария. Это позволит сократить человеческое участие в процессе обработки интернет-заказа.
В первую очередь (и это соответствует первоначальной постановке задачи по сценарию клиента) можно автоматизировать проверку наличия товаров по заказу.
Для этого мы можем просто удалить шаг «Проверить наличие товара» и проверку наличия товаров по заказу реализовать в шаге «Товар в наличии?».
Рисунок 27: Ручной шаг сценария «Проверка наличия товаров по заказу»
Рисунок 28: Автоматическая проверка наличия товаров по заказу
Для этого в шаге «Товар в наличии?» укажем алгоритм проверки. Алгоритм будет содержать программный код проверки остатков по массиву товаров из заказа.
|
Программный код здесь не приводится. В общих чертах – это «функция», которая выполнит запрос к регистру(ам) остатков (возможно, с учетом резервов и т.п.) по массиву товаров из заказа и вернёт результат. Значение переменной _Результат – это результат проверки. Если _Результат = Истина, то остатки товаров по заказу есть. Например, если в конфигурации уже есть подобная функция проверки, то можно использовать её _Результат = вн_Функции.ЕстьОстаткиПоЗаказу(_Процесс.Объект). |
Рисунок 29: Настройка шага автоматической проверки товара в наличии с указанием алгоритма проверки
Во вторую очередь (и это, также, соответствует первоначальной постановке задачи по сценарию клиента) можно автоматизировать подготовку документов отгрузки товаров по заказу.
Шаг-задача для пользователя «Подготовить документы для сборки/отгрузки» может быть заменен на шаг вида 
Обработка, в котором будет указан алгоритм, который автоматически сформирует все документы отгрузки по текущему заказу.
Рисунок 30: Ручной шаг «Подготовить документы для сборки/отгрузки»
Рисунок 31: Шаг автоматического формирования документов сборки/отгрузки
Рисунок 32: Настройка автоматического шага формирования документов с указанием алгоритма формирования документов
Аналогичным образом можно автоматизировать шаг «Сформировать счёт на оплату и отправить по шаблону покупателю».
Кроме этого, можно далее оптимизировать настройку, показанную на рисунке Рисунок 28: Автоматическая проверка наличия товаров по заказу.
Рисунок 33: Проверка наличия товаров с задержкой
Шаг «Задержка» нужен для того, чтобы после подтверждения от склада, что товар будет, повторная проверка наличия товаров выполнялась не сразу, а спустя некоторое время (например, на следующий день, или с учетом графиков поставок).
Т.е. склад ответил, что товар будет, программа ждёт n-ное количество часов/дней и снова проверяет наличие товара для продолжения процесса обработки заказа.
Эту конструкцию можно оставить как есть – она рабочая, а можно её оптимизировать, упростив саму схему.
Для этого мы удалим шаг «Задержка», а в настройках запуска шага «Товар в наличии» укажем отложенный запуск через 12 часов и установим галочку «Только при повторах».
Смысл настройки: после того, как менеджер подтвердит/согласует заказ, проверка товара в наличии будет произведена сразу (без задержки). Если товар в наличии есть, процесс продолжится по сценарию. Если товара в наличии нет – будет поставлена задача снабженцам по выяснению, будет ли товар по заказу на складе. Если снабжение ответит, что товар будет, то процесс вновь вернётся на шаг проверки наличия товаров. Только, в этот раз наличие товара будет проверено не сразу, а спустя указанное время (12 часов). Т.е. программа подождёт какое-то время и снова проверит наличие.
Рисунок 34: Настройка отложенного запуска
Рисунок 35: Проверка наличия товара
Рисунок 36: Отложенный запуск повторной проверки наличия товаров
Логика работы сценария осталась прежней, а схема сценария стала проще.
Кроме этого, в настройках шага «Товар будет?» можно настроить, чтобы пользователь указал дату появления товара на складе. В этом случае, можно запускать отложенный шаг именно этой датой.
Рисунок 37: Настройка шага сценария – обязательное указание даты с описанием «Когда будет товар»
Рисунок 38: Блок заполнения обязательных реквизитов в задаче, сформированной для пользователя
Рисунок 39: Отложенный запуск проверки наличия товара с датой, указанной в предыдущей задаче.
Таким образом, при настройках сценариев доступны различные варианты реализации и разная глубина настроек поведения системы по сценариям.
Напомним, что все указанные настройки выполнялись в режиме Предприятие, без использования режима Конфигуратор. Применение новых настроек сценариев происходит «на лету», т.е. новый функционал доступен сразу после записи сценария.
