Перед многими разработчиками и аналитиками встает задача автоматизации внутренних процессов компании, таких как обработка заявок, согласование документов или управление ремонтами. Часто возникает вопрос: какой инструмент платформы 1С лучше всего подходит для этого? Нужно ли углубляться в механизм Бизнес-процессов или можно обойтись более привычными объектами — документами и регистрами? Рассмотрим эту дилемму на примере конкретной задачи: автоматизация приема и контроля выполнения заявок на ремонт.
Исходная ситуация такова:
Ключевая сложность заключается в организации контроля за множеством этапов и исполнителей, а также в своевременном уведомлении сотрудников. Проанализируем два основных подхода к решению этой задачи.
Это стандартный, "коробочный" механизм платформы 1С, специально созданный для формализации последовательных действий сотрудников. Он идеально подходит для процессов с четко определенным маршрутом.
Как это работает в нашем случае?
Основной процесс "Обработка заявки" может выглядеть так:
Большим преимуществом этого подхода является наглядность. Вся логика процесса видна на Карте маршрута — визуальной схеме, которую легко понять и аналитику, и руководителю. Это значительно упрощает как первоначальную разработку, так и последующую поддержку и модификацию.
Этот подход предполагает отказ от объекта Бизнес-процесс в пользу собственной логики, построенной на более простых и знакомых каждому 1С-разработчику объектах. Этот способ отличается высокой гибкостью.
Как выстроить такую систему?
Заявка с реквизитом-перечислением Статус ("Новая", "В работе", "Выполнена", "Закрыта", "Отклонена").ЭтапРемонта (или Заказ-наряд), который подчинен Заявке. У него тоже есть свой реквизит Статус ("Запланирован", "В работе", "На проверке", "Выполнен").ИсторияСтатусовЗаявок для отслеживания, кто, когда и какой статус установил.Вся логика управления процессом "зашивается" в код, в основном в модули документов. Например, при проведении документа ЭтапРемонта со статусом "Выполнен", система должна проверить, все ли остальные этапы по родительской Заявке также выполнены. Если да, то можно автоматически изменить статус самой Заявки на "Выполнена".
Поскольку встроенного механизма задач у нас нет, систему уведомлений нужно создавать самостоятельно. Это можно сделать с помощью подписок на события. Например, при записи документа ЭтапРемонта в статусе "Запланирован" срабатывает подписка, которая отправляет уведомление назначенному исполнителю через встроенный "Центр оповещений" или по электронной почте.
Для удобства создаются специализированные отчеты и обработки — "Рабочие столы". Например, "Рабочий стол исполнителя", где он видит список только своих активных этапов, или "Отчет по просроченным заявкам" для руководителя.
Независимо от выбранного подхода, возникает важный практический вопрос: как убедиться, что пользователь не просто нажал кнопку "Выполнено", но и реально совершил требуемое действие (например, создал документ)?
Проанализируем несколько способов решения этой проблемы:
ОбработкаПроверкиВыполнения задачи можно написать код, который проверяет наличие связанного документа. Если документ не найден или не заполнен, выполнение задачи блокируется, и пользователю выводится сообщение.
// Пример проверки в модуле Задачи
Функция ОбработкаПроверкиВыполнения(Отказ, ТочкаМаршрутаБизнесПроцесса, ИмяКартыМаршрута)
// Предполагаем, что при создании документа мы в него записали ссылку на нашу задачу
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЭтапыРемонта.Ссылка
|ИЗ
| Документ.ЭтапРемонта КАК ЭтапыРемонта
|ГДЕ
| ЭтапыРемонта.ЗадачаИсполнителя = &Задача";
Запрос.УстановитьПараметр("Задача", Ссылка);
Результат = Запрос.Выполнить();
Если Результат.Пустой() Тогда
Сообщить("Необходимо создать и провести документ 'Этап ремонта' перед выполнением задачи!");
Отказ = Истина;
Возврат Ложь;
КонецЕсли;
Возврат Истина;
КонецФункции
Чтобы окончательно определиться с выбором, сведем ключевые характеристики обоих подходов в таблицу.
| Критерий | Бизнес-процессы и задачи | Система на регистрах и документах |
|---|---|---|
| Сложность разработки | Требует изучения механизма БП. Первоначальная настройка может быть сложнее. | Проще для разработчиков, хорошо знакомых с созданием документов и регистров. |
| Гибкость | Менее гибкий. Изменение логики требует перерисовки карты маршрута и может быть проблематичным для уже запущенных процессов. | Очень гибкий. Логику смены статусов и обработку событий можно легко изменять программно. |
| Наглядность | Высокая. Карта маршрута наглядно представляет весь процесс для всех участников. | Низкая. Вся логика "зашита" в коде и не очевидна для аналитиков или пользователей без изучения кода. |
| Контроль | Есть встроенные механизмы контроля выполнения задач, сроков, просмотра активных задач. | Требуется самостоятельная реализация всех механизмов контроля и отчетов. |
| Поддержка | Легче передавать на поддержку другому специалисту благодаря визуальной схеме. | Требует подробной документации и комментариев в коде, так как логика скрыта. |
Оба подхода имеют право на жизнь и успешно применяются на практике. Выбор зависит от специфики вашей задачи.
Выбирайте Бизнес-процессы, если:
Выбирайте систему на документах и регистрах, если:
В любом случае, какой бы путь вы ни выбрали, важно уделить особое внимание контролю выполнения ключевых действий, чтобы автоматизация приносила реальную пользу, а не создавала иллюзию порядка.