Веб-формы для создания бизнес-процессов

Коллеги, в связи с выходом нового программного продукта очень часто возникает масса вопросов по его функциональности. В частности очень часто спрашивают, можно ли сделать электронные заявки с подтверждением. Я всегда отвечаю, что да, можно. Но когда доходит до дела, даже опытные разработчики теряются.

Да, функциональность системы очень большая и может сбить столку. Поэтому хочу поделиться как можно использвать модуль веб-форм для построения бизнес-процессов в компании, используя программный продукт "1С-Битрикс: Корпоративный портал". Кстати, пользователям Управления сайтом тоже будет интересно.

Итак, электронные заявки. Но сначала предупреждение: далее следует очень длинный и подробный текст и около 1,5 Мб скриншотов.



[spoiler]

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

Из чего состоит этот процесс. Сотрудник компании подает зявку на доставку продуктов в офис. Эта заявка передается руководителю службы снабжения. Он может ее подтвердить или отклонить. Если он ее подтверждает, заявка переходят исполнителям, которые осуществляют закупку, доставку и т.д. Но и они по какой-то причине могут отклонить эту заявку (нет нужных продуктов в продаже).

Итого у нас получается три звена:
- составитель заявки
- руководитель службы снабжения
- исполнитель (сотрудник службы снабжения)

и четыре статуса такой заявки:
- принята
- подтверждена
- в работе
- отклонена

1. Группы пользователей.
Начнем мы разработку нашего процесса, пожалуй, с создания нужных нам групп пользователей. Пойдем в панель управления в настройки - пользователи - группы пользователей. И добавим новую группу пользователей, назвав ее "Руководитель хозяйственной службы" (за названия не ругайте).


В закладке "Доступ" обязательно укажите право "Чтение" на модуль Веб-форм.

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


Важно! Я предполагаю, что пользователи из этих групп пользователей будут работать с заявками через панель управления (через админку), поэтому нужно сделать один хитрый ход: открыть доступ на чтение папки /bitrix/admin. Иначе пользователь не сможет попасть в панель управления вообще. Для этого идем в "Контент", "Структура сайта", "Файлы и папки" и заходим в директорию /bitrix/admin и жмем "Свойства папки".


На открывшейся странице в закладке "Доступ" ставим этим группам пользователей параметр "чтение"


2. Пользователи.
После этого создадим пользователей в этих группах. Пользователи могут быть уже существующие (например вы их можете импортировать из AD или 1С:ЗУП), тогда нужно будет только сделать привязку к нужным группам. Начнем с руководителя хозяйственной службы, который принимает заявки и принимает по ним решение:



не забудьте привязать его к нужной группе пользователей:



и создадим сотрудника, который будет у нас исполнять заявки:



и обязательно сделаем привязку к нужной группе пользователей:



3. Создание формы.
Перед тем, как мы перейдем к созданию самой формы, зайдем в настройки модуля веб-форм и убедимся, что мы используем расширенный функционал модуля (это позволит нам использовать статусы и делать несколько уведомительных писем на изменение статуса). Галочка с параметра "использовать упрощенный режим редактирования веб-форм" должна быть снята:


Переходим к веб-формам. Идем в "Сервисы", "Веб-формы", "Настройка форм":


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


Введем описание, которое будет выводиться перед формой. Рекомендую сюда писать следующую информацию: что это за форма, для чего она нужна, что будет после ее заполнения (что ждать пользователю). Такой подход позволит избежать лишних вопросов со стороны пользователей и снизит нагрузку при обучении персонала работе с порталом.


Обязательно настроим доступ к данной форме для тех групп пользователей, которые мы создали на предыдущих шагах. Группам с руководителями и с исполнителями дадим доступ к работе с результатами заполнения форм в рамках предоставленного им доступа к статусам (как настраивается доступ статусов см. далее):


Часть закладок я пропустил, их содержимое не существенно для наших задач сейчас. Сохраним то, что у нас получилось и в списке форм мы увидим только что добавленную форму:

Обратите внимание на колонки "Вопросы" и "Статусы". Сейчас мы с ними поработаем.

4. Вопросы.
Начнем с вопросов: что нам необходимо узнать у пользователя для успешного исполнения его заявки? В моем случае я задаю пользователю три вопроса (какие продукты, когда нужно доставить и какие-то дополнительные комментарии), которые позволят однозначно исполнить его заявку. Вы можете создавать любое количество вопросов различных типов. Составляя вопросы думайте о том, достаточно ли будет ответов на указанные вопросы для исполнения заявки и не потребуют ли они какого-то дополнительного уточнения. Смысл в том, чтобы на этапе заполнения формы максимально опросить пользователя, чтобы не пришлось переспрашивать.

Нажмите на символ "+" в колонке "Вопросы", чтобы добавить вопрос в форму. Параметры первого вопроса:


Собственно, сам вопрос:


Ответ на данный вопрос. Напомню, что поле "Текст" нужно поставить пробел, если хотите оставить поле с ответом на вопрос пустым по умолчанию. Здесь вы указываете тип ответа (я выбрал для данного ответа textarea, т.к. в это поле предполагается писать какой-то текст):


Таким же образом сделаем вопрос "Дата доставки" (вопрос обязательный, тип Data) и "Комментарий" (вопрос необязательный, тип Textarea). В итоге получим список из трех вопросов:



5. Настройка статусов.
Статусы - это основа нашего процесса. Через череду таких статусов проходит заявка в процессе своего исполнения. Настройкой статусов можно настроить цепочку движения заявки через ответственных лиц. Нажмем кнопку "Статусы" в контекстном меню раздела Веб-формы:


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

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


На закладке "Уведомления" мы настроим почтовые сообщения, которые рассылаются участникам процесса:


Система нас просит сохранить статус перед изменением уведомительных сообщений. Нажмем "Применить":


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


Давайте настроим эти письма.
Письмо исполнителю будет у нас содержать следующую информацию (для редактирования я кликнул на ID данного шаблона в закладке "Уведомления" редактирования статуса):
* адрес "от" (задается обычно как DEFAULT_EMAIL_FROM, который при отправке письма заменяется электронным адресом по умолчанию, указанном в настройках главного модуля, но вы можете указать какой-то конкретрый адрес отправителя для каждого шаблона)
* "Кому" - сюда имеет смысл поставить адреса всех заинтересованных лиц, принимающих заявки
* Тема - заполняется в соответствии с задачей
* Тело сообщения - составляется таким образом, чтобы получивший данное письмо понимал, что это за письмо, почему оно ему пришло, что он должен с ним сделать и т.д. Хорошо в тело письма закидывать ссылки, чтобы пользователь мог перейти на страницу редактирования результата сразу из письма. Подробнее останавливаться не буду.


Аналогичным образом заполняем шаблон, отправляемый заявителю. Только в поле "Кому" ставим адрес заявителя (RS_USER_MAIL), а в теле письма разъясняем заявителю что будет твоиться с его заявкой далее:


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


Но это еще не все. Теперь самое интересное: настройка прав ответственных лиц.
Берем статус "Принята" и указываем кто какие действия может исполнять с данной заякой в этом статусе. С заявкой в конкретном статусе можно делать четыре вещи: переводить в этот статус, просматривать список результатов в этом статусе, редактировать результаты в данном статусе и удалять результаты в данном статусе.

Давайте порассуждаем, кто и что может сделать в статусе "Принята". Во-первых, пользователь заполнив форму подает заявку, а соответствующая служба ее принимает. Т.е. в статус "Принята" может переводить создатель результат. Принятую заявку будет изучать руководитель, значит просматривать заявку в статусе "принята" могут руководители хозяйственной службы (можно и сотрудникам этого отдела дать доступ на просмотр, но без редактирования, чтобы избежать произвола). Редактировать принятые заявки могут руководители. По поводу удаления - для сохранения истории я бы не давал обычным пользователям вообще возможности что-то удалять, а оставил такое право только за администратором портала. Вот такая картинка по правам у меня получилась:


Хорошо. Руководитель ознакомился с заявкой и теперь принимает решение дать ход заявке (передать в исполнение) или отклонить ее. Берем статус "В исполнении". Руководитель может переводить в данный статус. Исполнитель (сотрудник хозяйственной службы) может просматривать список заявок в этом статусе, может их редактировать. Руководство может внести коррективы в заявки в данном статусе. Удалять по прежнему даем только администратору:


Руководитель также может отменить заявку (например, дорого). Или исполнитель может отклонить заявку (например, нет в продаже). Тогда права на статус "Отменена" будут выглядеть следующим образом (приблизительно):


И остался у нас статус "Выполнено". Только исполнители могут ставить заявку в такой статус. Права будут выглядеть примерно так:


Из дополнительного про статусы: можно создавать статус "недостаточно данных" и дать пользователю право редактировать результаты в данном статусе. Это позволит возвращать заявку обратно заявителю в каких-то случаях на уточнение.

На этом создание формы у нас закончено. Давайте перейдем к полевым испытаниям.

6. Работа с формой.
Если вы тренируетесь на демонстрационной версии с демонстрационными данными как я, то данная форма уже доступна пользователям по адресу http://адрес_сервера/services/requests/form.php?WEB_FORM_ID=food (респект тому, кто знает, почему адрес такой. тому, кто не знает я с удовольствием подскажу).
Вот так это выглядит, давайте заполним:


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


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

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


Тут стоит оговориться, что вы вполне вправе сделать интерфейс в публичной части портала для руководителей, чтобы не гонять их в панель управления. Я бы для полного удобства задействовал бы раздел, который появился в последних обновлениях Корпоративного портала - "Мой портал", который можно персонолизировать. Для службы снабжения можно было бы написать свой компонентик для работы с заявками через публичную часть и сделать его частью "моего портала".


Но я отвлекся... Зайдя в заявки, пользователь увидет только те заявки, которые находятся в статусе, разрешенном для просмотра данному пользователю. Другими словами, заявки, которые не относятся к пользователю, он не увидит. Выглидит это так:


Это все заявки в статусе "Принято" (45й статус). Я могу открыть эту заявку, чтобы познакомиться с ней поближе. Обратите внимание на то, что будучи руководителем службы снабжения я могу либо отклонить данную заявку, либо передать ее на исполнение:


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

Тут мне нужно оговориться: в процессе подготовки я несколько раз проходил все эти процедуры и дал сотрудникам отдела снабжения доступ на просмотр заявок в статусе "принято" без возможности редактирования.

Итак, я выйду и зайду на портал как простой сотрудник отдела снабжения. Перейду сразу в панель управления:


Я увижу те же заявки. Но при попытке ее отредактировать я получу соответствующее предупреждение:


Пока все работает корректно и верно.

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


В это же время заявитель на портале будет наблюдать изменение статуса его заявки в разделе "Мои заявки" и при необходимости ему можно отправлять письма, информирующие его о состоянии его заявки.


*неужели вы до сюда дочитали? хвала вашему упорству!*

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

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

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

Если что-то непонятно или неполно описано, пожалуйста, спрашивайте! Обещаю, постараюсь ответить всем.