- Точка маршрута в запросе
- Как вывести карту маршрута на форме?
- Ручное управление
- Признак завершенности бизнес-процесса
- Признак выполнения задачи
- Удаление задач
- Добавление задач
- Системы управления бизнес-процессами и административными регламентами (на примере свободного ПО RunaWFE)
- Элементарные процессы
- Ознакомление
- Рассмотрение
- Исполнение
- Регистрация
- Согласование
- Утверждение/Подписание
- Комплексные процессы
- Использование интерфейса OData в сервисе 1С
- Анализ бизнес-процессов
- Автоматизация маршрутизации
- Прикладные задачи использования иерархии в 1С
- Иерархии нет, а если найду?
- Иерархия в отчете приготовления блюд
- Если нам нужен иерархический вид, а его нет
- Диаграмма структуры организации за 5 минут
- Оптимизация «Структурных единиц»
Точка маршрута в запросе
1.
Сейчас в теме
Добрый день! Пытаюсь вывести в отчет данные потконткретным действиям из бизнес процесса, однако не могу написать правильный отбор, постоянно жалуется. много вариантов констркций перепробовал уже. ЗадачаИсполнителяПредметы.Ссылка.ТочкаМаршрута = ЗНАЧЕНИЕ(БизнесПроцесс.КомплексныйПроцесс.ТочкаМаршрута.Действие5)
3.
M_I_V_91
Сейчас в теме
(2)Победил, УРА!!!
ЗадачаИсполнителяПредметы.Ссылка.ТочкаМаршрута = ЗНАЧЕНИЕ(БизнесПроцесс.ИСполнение.ТочкаМаршрута.Исполнить)
+
Ответить
2.
glek
Сейчас в теме
Оставьте свое сообщение
E-mail:
Введите ваш E-mail
Как вывести карту маршрута на форме?
Создадим форму бизнес-процесса. Добавим реквизит формы КартаМаршрута с типом ГрафическаяСхема:
Рисунок 1 – Создание реквизита «КартаМаршрута» формы бизнес-процесса
Перенесем созданный реквизит на форму. Получим поле графической схемы, связанное с реквизитом КартаМаршрута:
Рисунок 2 – Размещение созданного реквизита на форме
Теперь необходимо, чтобы в этом поле графической схемы отображалась карта маршрута текущего бизнес-процесса, форма которого открыта.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Ручное управление
Признаки завершения бизнес-процесса и выполнения у задачи можно устанавливать вручную, в обход механизма бизнес-процессов, однако делать это нужно с полным пониманием всех возможных последствий.
Признак завершенности бизнес-процесса
Если установить признак завершенности, то бизнес-процесс будет считаться завершенным, даже несмотря на то, что связанные с ним задачи еще не выполнены. И при выполнении этих задач завершенный бизнес-процесс уже не будет двигаться дальше по маршруту.
Признак завершения можно установить у нестартованного бизнес-процесса. В этом случае его старт в дальнейшем будет невозможен.
Если вручную снять признак завершения с завершенного бизнес-процесса, то связанные с ним задачи все равно останутся выполненными. Таким образом, бизнес-процесс не будет завершен, но по нему не будет ни одной невыполненной задачи. Повторный старт такого бизнес-процесса невозможен, т. к. система будет считать его стартованным (по нему есть одна или более задач). Поэтому при ручном снятии признака завершения следует снять признаки выполнения у нужных задач таким образом, чтобы вернуть бизнес-процесс на нужную точку маршрута.
Признак выполнения задачи
Если установить признак выполнения задачи вручную, то это не приведет к продвижению бизнес-процесса дальше по маршруту. При этом также не будут вызваны обработчики событий ПередВыполнением() и ПриВыполнении() у задачи и соответствующей ей точке маршрута.
Ручная установка признака выполнения может привести к остановке бизнес-процесса ‑ он не будет завершен, но по нему не будет ни одной невыполненной задачи.
Снятие признака выполнения у задачи может привести к появлению параллельного потока в незавершенном бизнес-процессе. Допустим, бизнес-процесс еще не завершен и по нему есть одна выполненная и одна невыполненная задача. Если снять признак выполнения с выполненной задачи, то у данного бизнес-процесса появятся две невыполненные задачи. При выполнении каждой из них бизнес-процесс будет двигаться дальше по карте маршрута от точки, соответствующей выполненной задаче. При этом бизнес-процесс будет считаться завершенным, когда все задачи в обеих параллельных ветвях будут выполнены.
Снятие признака выполнения у задачи, бизнес-процесс которой уже завершен, приведет к тому, что задача будет видна в списках как невыполненная, но ее выполнение не будет продвигать бизнес-процесс дальше по маршруту.
Удаление задач
Если удалить невыполненные задачи незавершенного бизнес-процесса, то он может остановиться. Такой бизнес-процесс будет незавершенным, но по нему не будет ни одной активной (невыполненной) задачи.
Задачи используются для отображения реальной карты маршрута бизнес-процесса, чтобы показать уже пройденные точки маршрута и активные (невыполненные). Поэтому удаление задач может привести к некорректному и противоречивому отображению пройденных и активных точек маршрута.
Удаление всех задач для незавершенного бизнес-процесса переводит его в статус нестартованного.
Добавление задач
Если вручную создать новую задачу по завершенному бизнес-процессу, то бизнес-процесс все равно будет считаться завершенным и выполнение этой задачи не приведет к его продвижению по карте маршрута.
Если вручную создать новую задачу для еще не стартовавшего бизнес-процесса, то он получает статус стартованного и выполнение этой задачи приведет к его продвижению дальше по карте маршрута.
Создание новой задачи для уже стартовавашего и незавершенного бизнес-процесса приводит к его распараллеливанию.
Системы управления бизнес-процессами и административными регламентами (на примере свободного ПО RunaWFE)
Принято считать, что современная система управления бизнес-процессами и административными регламентами (далее СУБПиАР) должна обеспечивать разработку бизнес-процесса в графической среде, исполнение бизнес-процесса, мониторинг состояния бизнес-процесса, ведение истории событий бизнес-процесса, интеграцию приложений при помощи используемых бизнес-процессами коннекторов, администрирование пользователей, а также возможность замещения исполнителей заданий.
Для выполнения этих функций в СУБПиАР служат следующие графические интерфейсы:
Для разработки бизнес-процессов обычно применяются графические дизайнеры бизнес-процессов, которые являются отдельными приложениями.
В системе RunaWFE для интеграции приложений реализованы специальные сущности – боты и бот-станции.
В данной части методического пособия на примере системы RunaWFE продемонстрирована вся перечисленная функциональность и пользовательские интерфейсы.
Элементарные процессы
Это основные процессы, на основе которых строятся базовые взаимодействия между сотрудниками. Исходя из их наименований, понятно их назначение и что они делают. К элементарным процессам относятся:
Рис.3 Список шаблонов процессов
Ознакомление
Это довольно простой процесс, но очень нужный. Этот процесс создает задачи для пользователей системы электронного документооборота – «Ознакомиться».
В карточке задачи имеется информация:
Рис.4 Карточка процесса «Ознакомление»
Рис.5 Задачи, которые появились у процесса
Рис.6 Карточка задачи, как ее видит пользователь
Рассмотрение
Рассмотрение – это процесс для получения резолюции, запрос решения от Руководителя. Как правило, этот процесс всегда имеет вложенный документ, который необходимо рассмотреть.
Рис.7 Схема процесса рассмотрения
Рис.8 Процесс рассмотрения документа в 1С:Документообороте
Рис.9 Задача рассмотрения в 1С:ДО. Исполнитель пишет свою резолюция и нажимает «Рассмотрено». Резолюции могут быть выбраны из подготовленных заранее шаблонов резолюций
Рис.10 Обработка резолюции – пользователь, который делал запрос резолюции, получает решение руководителя и обрабатывает резолюцию. Отправляет на Исполнение или на Ознакомление, в зависимости от содержания резолюции
Рис.11 В карточке документа на закладке «Резолюции» добавляются все резолюции по документу. Их может быть несколько, от разных руководителей
Исполнение
Исполнение – это, наверное, один из основных механизмов для взаимодействия сотрудников. Инициатор процесса поручает, а Исполнитель/Исполнители выполняют поставленную задачу.
Рис.12 Схема процесса Исполнение
Исполнителями процесса могут быть как конкретные пользователи, так и роли. При подборе исполнителей можно использовать подбор по группам пользователей. В этом случае в список исполнителей одним кликом добавятся все участники рабочей группы.
Процесс Исполнения может формировать задачи исполнителям по трем сценариям:
Один из исполнителей может быть назначен ответственным за отработку процесса. Он сможет выполнить свою задачу только после того, как все соисполнители выполнят свои задачи.
После выполнения всех задач, появляется задача «Проверить исполнение». У проверяющего есть два сценария действия:
Следует отметить функцию контролера процесса. Его задача — отслеживать сроки исполнения, регламент выполнения. Задача контролировать появится вместе с задачами для исполнителей. Контроль будет автоматически завершен вместе с процессом исполнения.
Рис.13 Карточка процесса Исполнение. Указаны Проверяющий и Контролер
Циклов исполнения может быть сколько угодно много, до полного корректного выполнения заданий.
При настройке шаблонов процесса исполнения могут быть использованы условия, при которых исполнители подключаются или нет к выполнению задачи. Например, если сумма в документе более 1 млн рублей, то соисполнителем должен быть добавлен финансовый директор.
Бесплатная консультация эксперта
Спасибо за Ваше обращение!
Специалист 1С свяжется с вами в течение 15 минут.
Регистрация
Процесс регистрации позволяет автоматизировать регистрацию документов. Этот процесс не имеет смысла в отрыве от документа.
Когда инициатор работает с документом, и по регламенту необходимо выполнить регистрацию документа, это делается просто нажатием кнопки «Зарегистрировать». Документу присваивается регистрационный номер и его статус меняется на «Зарегистрирован». Как правило, в этот момент документ закрывается в режим «Только просмотр», если не предусмотрено его другое поведение.
В тех случаях, когда с документом работает много разных людей и действие по регистрации документа (при этом обычно проводится проверка заполнения и вложенных файлов) выполняется специальным человеком, то используется именно процесс Регистрация.
Рис.14 Процесс регистрации документа
В основном процесс регистрации активно используется при работе с входящими и исходящими документами. Здесь это необходимо по нормам делопроизводства.
Регистрация актуальна и при работе с внутренними документами. Например, чтобы обработать Заявку на оплату (финансовую заявку), в которую прикреплен счет на оплату, необходимо:
При обработке договоров их регистрация происходит в процессе комплексной обработки договора. Обычно после его согласования. В этот момент договор идет на регистрацию, ему присваивается номер, но договор не обязательно полностью закрывается от изменений. В карточку договора могут добавляться новые файлы, могут меняться дополнительные реквизиты (условия поставки, дата и номер оплаты по договору и т.д.).
Оптимальное для вас решение подберут эксперты-практики внедрения СЭД на базе 1С. Консультация бесплатно
Согласование
Согласование — ключевой процесс при взаимодействии сотрудников в компании. Необходимо согласовывать документы, вносить замечания, правки во вложенные в карточку документа файлы, собирать визы согласующих. Делать это в нужном порядке и с теми согласующими, кто нужен по контексту документа.
Настроенных шаблонов (маршрутов согласования) в программе «1С:Документооборот 8 КОРП» может быть много:
Рис.15 Шаблоны процесса согласования в 1С:Документообороте
Для процесса согласования так же, как и для исполнения существует несколько вариантов:
Согласующие могут подключаться к процессу согласования по условиям. Например, руководитель подразделения участвует в согласовании, только если вопрос деятельности имеет отношение к его подразделению. Финансовый директор подключается всегда при определенных суммах, и не подключается к документам, которые носят характер внутреннего перемещения денег. А генеральный директор может не согласовывать определенные виды документов (например, банковского обслуживания), а для определенных документов его участие обязательно.
Рис.16 Процесс согласования, параллельно-последовательное, по ролям, с условиями участия согласующих
Условий для участия в процессах может быть много, как простых, так и достаточно сложных.
Рис.17 Пример сложного условия маршрутизации
После прохождения согласования на закладке «Визы» в карточке документа собираются результаты согласования, с комментариями согласующих. Там же можно распечатать лист согласования, в том числе с историей, если было несколько циклов согласования.
Рис.18 Визы согласующих в карточке документа с комментариями
Результат согласования может быть:
Рис.19 Карточка задачи для согласования. Три варианта выполнения задачи. Из задачи можно сразу перейти в карточку согласуемого документа или открыть любой вложенный в документ файл
Если согласование закончилось с результатом «Не согласовано», то в задаче инициатору согласования (автору процесса) можно выбрать один из вариантов:
Рис.20 Задача ознакомиться с результатами согласования. Есть возможность внести исправления по замечаниям от согласующих и повторить согласование в рамках этого же процесса
После согласования можно распечатать лист согласования с историей изменений. Часто лист согласования подшивается к договору при подписании документа генеральным директором. В листе согласования отражаются все замечания и дата с привязкой ко времени выдачи визы к договору.
Рис.21 Лист согласования с историей
Утверждение/Подписание
Процесс используется для передачи документа на утверждение или подписание в зависимости от контекста документа. Процесс адресует задачу на ответственное лицо или на функциональную роль.
Рис.22 Схема процесса Утверждение/Подписание
При старте процесса состояние документа меняется – «На утверждении/На подписании», а после завершения процесса – «Утвержден/Подписан» или «Не утвержден/не подписан».
В процессе может быть установлен флаг «Подписывать ЭП» (электронной подписью).
У ответственного есть два варианта выполнить задачу:
Рис.23 Задача «Утвердить» с двумя вариантами ее выполнения
В случае неудачного утверждения документ можно отправить на повторное утверждение/подписание аналогично процессу согласования. Безусловно, стоит перед повторной отправкой устранить замечания ответственного.
Бесшовная интеграция 1С:Документооборот с программами 1С. Гарантия на услугу в договоре!
Комплексные процессы
Комплексные процессы состоят из набора действий, которые должны быть выполнены в определенном порядке, возможно, с применением условий. В составе комплексного процесса может быть другой комплексный процесс. Таким образом, через этот мощный механизм можно организовать какой угодно сложности процесс обработки документа.
Составляющими комплексного процесса могут быть:
В проектировании сложных процессов следует руководствоваться разумными соображениями. Процессы могут быть достаточно сложными в жизни, их желательно разбивать на более мелкие законченные шаги. Процесс должен быть «понятен», и его логика не должна быть очень уж сложной.
Рис.24 Пример (полный) сложного комплексного процесса из реального проекта
Рис.25 Фрагмент схемы сложного комплексного процесса. Пример перегруженной логики, с этим сложно работать даже специалисту по схемам процессов
Комплексные процессы можно настраивать:
Ниже для сравнения приведем один и тот же процесс, настроенный в схеме и в таблице. В обсуждениях специалистов выясняется, что функциональность никак не меняется, дело вкусов и предпочтений в восприятии материала.
Рис.26 Комплексный процесс в схеме
Рис.27 Комплексный процесс в таблице
Автор статьи, как специалист с огромным опытом работы на реальных проектах, считает, что работа в таблицах более удобна. Это чистая логика, без перевода логики «в картинки», которые, конечно, удобнее показывать на совещаниях, представителям заказчика, далеких от работы с программой. Опять же, если схема визуально простая. Все это дело вкуса и условий коммуникации с заказчиком, не более.
В реальных проектах при работе с документами обойтись элементарными процессами не получится. Практически все делается именно на комплексных. Это связано с тем, что процесс в реальности более сложен, чем просто «согласовать договор».
Например, после того как создан стандартный договор, начинается его обработка:
Ниже примеры настройки комплексных процессов с реальных проектов.
Рис.28 Примеры настроенных комплексных проектов
Рис.29 Набор элементарных процессов в составе комплексного процесса
Для шаблонов процессов предусмотрена возможность автоматического старта процесса. Это позволяет стартовать процесс по событию без участия пользователя. От пользователя требуется просто аккуратно по шаблону создать новый документ, заполнить в нем все поля, прикрепить файлы и нажать кнопку «Записать и закрыть». Назначенный для таких документов процесс стартует автоматически.
Чем меньше требуется действий от пользователя, тем меньше ошибок в работе системы возникает. На этапе настройки опытными специалистами максимально снижается риск проявления «человеческого фактора», когда пользователь может выполнить ошибочное действие, например, запустить другой неправильный процесс.
Рис.30 Настроен автоматический старт процесса по событию Создан новый документ
Не знаете, какую конфигурацию выбрать? Смотрите таблицу сравнений версий 1С:Документооборота
Использование интерфейса OData в сервисе 1С
В сервисе 1С:Фреш (1cfresh.com) все прикладные информационные базы опубликованы с включенной поддержкой интерфейса OData.
Анализ бизнес-процессов
Применяется два вида анализа бизнес-процессов:
1. С целью проверки эффективности эксплуатирующихся бизнес-процессов (Для того, чтобы «Делать вещи правильно»)
2. Для последующего перепроектирования бизнес-процессов (Чтобы после этого «Делать правильные вещи»).
Случай «Делать вещи правильно» в основном относится к оценке эффективности исполнения экземпляров бизнес-процесса. В рамках этого вида анализа проверяется, насколько бизнес-процесс соответствует установленным регламентам, насколько оптимально он использует ресурсы и т.п..
Случай «Делать правильные вещи» в основном относится к определению бизнес-процесса. Данный вид анализа дает ответ на вопрос: выполняет ли бизнес-процесс то, что требуется с точки зрения бизнеса? То есть, если бизнес-процесс по каким-то причинам перестал соответствовать бизнес-цели предприятия, то не имеет смысла добиваться его максимальной производительности. Вместо этого надо сначала изменить бизнес-процесс так, чтобы его выполнение способствовало достижению бизнес-цели. В частности, если продукт (услуга), производимый бизнес-процессом, перестал пользоваться спросом на рынке, то не надо оптимизировать ресурсы для производства этого продукта. Надо прекращать производство этого продукта и переходить к выпуску нового продукта, обладающего рыночным спросом (пусть даже в начальный период производство нового продукта будет неоптимальным).
Анализ бизнес-процессов в обоих случаях в конечном счете должен показать, насколько эффективно бизнес достигает своих целей. Анализ применяется к текущему состоянию бизнеса («как есть»). Однако, если анализ производится с целью дальнейшего перепроектирования бизнес-процессов, результаты анализа будут использованы для перевода бизнеса в новое (желаемое) состояние («как должно быть»), а также для обоснования требований к необходимым для этого ресурсам.
В случае проверки эффективности эксплуатирующихся бизнес-процессов, анализ достижения бизнес-целей должен выполняться на постоянной основе.
В случае анализа для последующего перепроектирования («Делать правильные вещи») начинать анализ можно уже в ходе обследования и проектирования бизнес-процессов «как есть». При проведении анализа нужно обращать внимание на возможности совершенствования: следует выделять избыточные действия, бессмысленные действия, действия не имеющие ценности с точки зрения заказчика, а также задержки, возникающие вследствие неоптимальных согласований. В ходе обследования необходимо идентифицировать и описать все имеющимся проблемы. После перепроектирования бизнес-процесса вся выполняемая в нем работа должна вносить вклад в достижение бизнес-цели.
На этапе анализа могут применяться следующие способы сбора информации (совпадающие с некоторыми способами, используемыми на этапе проектирования):
Анализ бизнес-процессов исследует выполнение действий бизнес-процессов и измеряет результаты этих действий, сопоставляя их с целями бизнеса.
Анализ одного бизнес-процесса обычно недостаточен. Необходимо рассмотреть, как изменение одного бизнес-процесса может влиять на другие бизнес-процессы. Чтобы правильно выбрать рамки анализа, надо принять во внимание контекст бизнес-процесса и его ценность для заказчиков и других процессов. В первую очередь должны быть проанализированы бизнес-процессы, непосредственно отвечающие за достижение целей предприятия и оказывающие влияние на существенный для бизнеса результат.
Автоматизация маршрутизации
Трейд-маркетинговое агентство Open Group, имеющее 20-летний опыт в сфере комплексных решений по управлению продажами и полевым персоналом, работая с тысячами мерчандайзеров и масштабируя свои услуги, на определенном этапе развития начала испытывать трудности с эффективным распределением времени, необходимым на маршрутизацию. «Это стало для нас триггером и отправной точкой для поиска решений, – рассказывает Дмитрий Осоловский. – Мы замерили, сколько времени менеджеры тратят на построение маршрутов, прикинули, сколько времени высвободится, если внедрить специальные инструменты, и как от этого повысится эффективность бизнеса. В поиске решения мы изучили все проблемы, решения и накопили свою экспертизу использования ПО. Совместили преимущество лучших технологий и экспертизу специалистов и создали сервис по маршрутизации».
Компания Open Group владеет несколькими инструментами, на базе которых можно настраивать маршрутизацию, имеет штат инженеров с большим опытом работы, поэтому оказывает услугу маршрутизации на аутсорсинге, подбирая под каждого клиента индивидуальные решения. Никогда не использует просто автоматическое распределение, уделяя внимание особенностям каждого пути и маршрута.
После получения брифа от клиента специалисты Open Group тщательно оценивают все детали и факторы требуемого маршрута – автодорожное движение, общественный транспорт, препятствия, нагрузку в рамках территории и каждого дня.
«Зачастую супервайзеры и инженеры в компаниях нарезают маршрут методом простого деления количества рабочих часов на количество точек, – говорит Дмитрий Осоловский. – Без специальных инструментов практически невозможно определить, как нагрузка распределяется в течение дня и недели, поэтому получается, что в понедельник человек работает 10 часов, а во вторник – 6 часов. Мы равномерно распределяем нагрузку так, чтобы удобно было работать 8 часов в день и выполнять все задачи».
Специалисты Open Group учитывают любые пожелания по построению маршрута, например, поставщику важно, чтобы 70% визитов его мерчандайзеров совпадали со временем поставки в эту торговую точку. Или на участке есть железная дорога с опасным переходом, и лучше его миновать. Все маршруты выстраиваются под запрос.
Сервисная компания берет на себя ответственность за результат. «На уровне брифа мы вместе с заказчиком определяем, какими будут результаты, – рассказывает Дмитрий Осоловский. – Например, сейчас трэвел-тайм, время на переход между точками, занимает у мерчандайзера 1/8 рабочего дня, мы договариваемся, что теперь это будет 1/10. Определяем количество точек, маршрутов, вносим изменения и получаем обратную связь. Сопровождаем клиента 24/7».
Для клиента делается наглядная аналитика, показывающая, какие результаты были до внедрения и какие получены. Например, сколько времени мерчандайзер раньше тратил на переход, куда не успевал доходить, сколько точек успевал обрабатывать. Предлагается несколько сценариев в зависимости от потребностей клиента. Например, задача – увеличение покрытия: если раньше, условно, за 100 руб. отрабатывалось 5 точек, то теперь за те же деньги успевают отрабатывать 10 точек. Или – задача сэкономить средства: если 100 точек отрабатывается за 100 руб., можно оптимизировать маршрут так, чтобы 100 точек покрывать за 90 руб., – бюджет будет сэкономлен на 10%.
Есть два вида сотрудничества. Первый вариант – разовая маршрутизация и сервисная поддержка в течение первого месяца для корректировок. Второй вариант – годовая подписка, два раза в год – полноценная маршрутизация и каждый месяц – внесение необходимых изменений.
Прикладные задачи использования иерархии в 1С
Как вы могли заметить технологическая платформа «1С:Предприятие 8» предоставляет различные возможности построения иерархии. Однако всегда ли их хватает и всегда ли результат ожидаемый?
Для того, чтобы ответить на данный вопрос, давайте рассмотрим пару кейсов, которые произошли у нас на проектах за последнее время.
Иерархии нет, а если найду?
Одной из особенностей платформы 1С:Предприятие 8 является отключение отображения иерархии при отборах, кроме необходимых ей для построения самой иерархии.
Можно предположить, что так было сделано по причине неясности ожиданий пользователя. Например, нужен ли ему просто быстрый поиск значения или же он ожидает увидеть и иерархию недоступную для выбора. Что делать если задача отобразить эту иерархию все-таки есть или нужно сформировать общую иерархию двух таблиц?
Возможно, эта задача покажется сложной и весьма не очевидной. Однако, для таких задач можно использовать механизм схемы компоновки данных, а точнее его возможности связи наборов данных.
Давайте рассмотрим использование этого механизма на примере. В библиотеке стандартных подсистем существует механизм дополнительных реквизитов и сведений. Данный механизм позволяет расширять структуру объектов метаданных из режима «1С:Предприятие». Благодаря этому типовые решения могут подходить самым разным клиентам, не углубляясь в тонкости отрасли.
Подготовим новый дополнительный реквизит «Инвентарь» для справочника «Сотрудники» и заполним его у текущих сотрудников.
Далее перед нами появляется задача отобразить все значения данного реквизита, а также их владельцев. Для применения механизма схемы компоновки данных необходимо подготовить таблицу с матрицей связей между элементами. В данной ситуации она будет состоять из объединения таблиц инвентаря и сотрудников. В таблице инвентаря матрица связи является хранимой и описывается реквизитами «Ссылка» и «Родитель», где «Ссылка» является источником, а «Родитель» — приемником.
При этом у таблицы сотрудников источником будет выступать аналогично реквизит «Ссылка», а вот приемником — значение дополнительного реквизита.
ВЫБРАТЬ
СправочникЗначений.Ссылка КАК Источник,
СправочникЗначений.Родитель КАК Приемник
ИЗ
Справочник.ЗначенияСвойствОбъектов КАК СправочникЗначений
ГДЕ
СправочникЗначений.Владелец = &ДополнительныйРеквизитВЫБРАТЬ
ТЧДополнительныеРеквизиты.Ссылка,
ТЧДополнительныеРеквизиты.Значение
ИЗ
Справочник.Сотрудники.ДополнительныеРеквизиты КАК ТЧДополнительныеРеквизиты
ГДЕ
ТЧДополнительныеРеквизиты.Свойство = &ДополнительныйРеквизит
Затем подготовим макет схемы компоновки данных, где создадим набор данных с двумя полями «Источник» и «Приемник». В данном примере на входе набора данных мы используем внешний набор данных, что позволяет нам максимально гибко подготовить исходные данные для формирования иерархии. Однако это не является ограничением использования данного подхода и при желании можно использовать и другие источники наборов данных.
Далее перейдем на вкладку связи наборов данных и добавим правило связи, где укажем поля источника и приемника, а также начальное значение связи.
На вкладке настройки добавим пустую группировку и заполним выбранные поля соответствующими значениями.
Подготовив данный макет останется последовательно инициализировать все элементы компоновки данных и заполнить реквизит с типом дерево на форме.
// Получение макета СКД.
СхемаКомпоновкиДанных = Справочники.ЗначенияСвойствОбъектов.ПолучитьМакет(«УОП_ИерархияЗначений»);// Инициализация компоновщиков.
КомпоновщикНастроек = Новый КомпоновщикНастроекКомпоновкиДанных;
КомпоновщикНастроек.Инициализировать(Новый ИсточникДоступныхНастроекКомпоновкиДанных(СхемаКомпоновкиДанных));
КомпоновщикНастроек.ЗагрузитьНастройки(СхемаКомпоновкиДанных.НастройкиПоУмолчанию);КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных,
КомпоновщикНастроек.Настройки,,,
Тип(«ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений»));ВнешнийНаборДанных = Новый Структура(«ТаблицаЭлементов», ТаблицаСвязей);ПроцессорКомпоновкиДанных = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновкиДанных.Инициализировать(МакетКомпоновки, ВнешнийНаборДанных); // Подготовка и заполнение дерева иерархии.
ДеревоИерархии = Новый ДеревоЗначений;ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначений;
ПроцессорВывода.УстановитьОбъект(ДеревоИерархии);
ПроцессорВывода.Вывести(ПроцессорКомпон
В результате можно получить вот такое дерево элементов, где к основной иерархии элементов инвентаря был добавлен дополнительный уровень с сотрудниками.
Тут важно понимать, что в данном случае мы занимаемся так называемой декларативной частью разработки. То есть описываем, какие именно поля связываются, чтобы образовать матрицу связности, а ее построением и рекурсивным обходом занимается «черный ящик» СКД, за что ему большое спасибо!
Таким образом, для решения задачи формирования иерархии разнотипных сущностей и формировании сложных деревьев можно использовать механизм схемы компоновки данных платформы «1С:Предприятие 8». Данный подход является универсальным и подходит для решения большого количества задач связанных с формированием иерархии.
Иерархия в отчете приготовления блюд
В предыдущем примере мы рассмотрели базовый вариант, когда иерархия одной из таблиц уже являлась хранимой. Однако, на практике так бывает далеко не всегда. Следующая история произошла при разработке «Отчета по плановой себестоимости» конфигурации «1С:Предприятие 8. Общепит, редакция 3.0».
Данный отчет отображает плановую себестоимость приготовления блюд по ингредиентам с учетом разложения их полуфабрикатов. При этом для оценки каждого блюда или полуфабриката используются только актуальные рецептуры на конкретную дату. Соответственно состав входящих полуфабрикатов от времени может меняться, т. е. не является хранимым.
Пример построенного отчета.
Если мы посмотрим на пример сформированного отчета, то можно увидеть все уровни приготовления блюда «Пюрешка с котлеткой и огурчиком» согласно его рецептуры.
Что же из себя представляет эта рецептура? Рецептура приготовления является документом, в котором в шапке указывается блюдо и количество, которое получается на выходе, а в табличной части указан состав ингредиентов, необходимый для его приготовления. При этом ингредиентом может выступать и полуфабрикат, который по сути является таким же блюдом со своей рецептурой приготовления.
Получается, что на уровне объекта метаданных связь между блюдами и ингредиентами определяется лишь объектно, а не двумя реквизитами, но иерархию построить нужно. Для этого мы используем тот же самый принцип со схемой компоновки данных, а именно, сначала готовим таблицу производства, где описывается связь между блюдами и ингредиентами, затем она передается схеме компоновки данных и результат выводится в отчет.
Построение таблицы производства осуществляется в несколько этапов:
Для сохранения связей между блюдами и ингредиентами при построении таблицы производства заполняются служебные колонки «Ключ источника» и «Ключ приемника». Ключ источника идентифицирует конкретную строку приготовления. Он может быть представлен уникальным идентификатором или же просто числом, которое постепенно увеличивается. Ключом приемника является ключ источника блюда/полуфабриката для приготовления которого и нужен этот ингредиент.
В результате получим следующую таблицу производства.
Полученную таблицу помещаем в качестве набора данных.
На вкладке связи наборов указываем поле «Ключ источника» в качестве выражения источника и «Ключ приемника» в качестве выражения приемника.
Для группировки колонок «Блюдо» и «Ингредиент», а также «Количество блюда» и «Количество ингредиента» подготовим соответствующие вычисляемые поля «Номенклатура» и «Количество», которые будем заполнять в зависимости от типа строки.
На вкладке настройки укажем выбранные поля.
После компоновки данных получается отчет с иерархией по каждому уровню производства.
По итогу, вследствие использования схемы компоновки данных для формирования иерархии, результат можно представить как в виде дерева элементов, так и в табличном документе.
Если нам нужен иерархический вид, а его нет
Давайте представим себе ситуацию, что к вам приходит клиент и говорит, что у вас справочник не иерархический, а нам нужен именно иерархический и все доводы ни к чему не приходят.
Схожая ситуация у нас произошла при разработке «1С:УНФ 8. Управление предприятием общепита», в котором справочник «Дисконтные карты» являлся линейным, но с подчинением справочнику «Виды карт». Однако подчинение другому справочнику не решало все возможные ситуации. Потому мы решили это исправить.
Для этого мы сначала включили свойство справочника иерархический и выбрали вид иерархии.
Однако если запустить такой справочник и попробовать создать группу, то режим отображения останется список и переключение на другие варианты будет недоступно. Даже если вы заполните у элементов реквизит «Родитель».
Данное поведение связано с тем, что данный справочник является подчиненным и для построения иерархии платформе требуется отбор по полю владельца.
Стоит отметить, что если попробовать просто выполнить группировку по полю владельца, то платформа все равно не отобразит иерархию.
Диаграмма структуры организации за 5 минут
К вам приходит начальник и просит показать структуру организации в графическом виде, а до совещания осталось пару минут — не беда.
Для построения диаграмм на платформе «1С:Предприятие 8» можно воспользоваться табличным документом, графической схемой или полем HTML. Однако, при использовании табличного документа или графической схемы разработчику потребуется генерировать объекты, связи между ними и смещать относительно друг от друга.
Пока речь идет о прямой линейной структуре это звучит не так страшно. Хотя и за короткое время решить не получится. Однако если структура дерева начинает ветвится или имеет петли? В такие моменты приходит на помощь поле HTML. В частности для реализации данной задачи можно воспользоваться библиотекой динамической визуализации Vis.js. Она проста в использовании и предоставляет возможность обработки большого объема данных.
Для инициализации дерева с помощью библиотеки необходимо подготовить список узлов и таблицу ребер. В качестве примера представим следующую структуру организации:
Представим структуру данной организации в виде соответствующих коллекций узлов и связей между ними.
Коллекция связей между узлами (Таблица ребер):
Преобразуем данные коллекции в строки скрипта инициализации дерева.
Добавим определение места размещения дерева и передадим необходимые параметры для инициализации.
Разместим текст итогового скрипта в исходную HTML-разметку. В результате запуска получим следующую картинку:
Если же написать заполнение этих коллекций на основании результата запроса по нужным нам таблицам, то в качестве узлов будут выступать уникальные идентификаторы ссылок, а связь между узлами может быть описана идентификаторами реквизитов «Ссылка» и «Родитель».
Таким образом, благодаря использованию библиотеки Vis.js можно формировать сложные диаграммы связи между объектами за считанные минуты.
Оптимизация «Структурных единиц»
Случай произошел при внедрении типового продукта «1С:УНФ 8. Управление предприятием общепита» у крупного промышленного предприятия. Пользователи системы открывали форму выбора структурных единиц и время ее открытия составляло от 2 до 5 минут, что, конечно, не считалось приемлемым. При этом в качестве системы управления базами данных использовалась Microsoft SQL Server 2017, а технологическая платформа была версии 8.3.18.1289.
Для того, чтобы разобраться с этой проблемой давайте посмотрим на саму форму выбора. Она состоит из динамического списка, полей отборов и вывода контактной информации.
Если ее запустить с замером производительности, то в результате в лидерах можно увидеть: обход всех строк динамического списка методом ПриПолученииДанныхНаСервере.
Данные строки кода действительно создают задержку при отображении списка. Однако их продолжительность не занимает все время и лидирующую позицию занимает событие открытия формы. Из чего можно предположить, что данная форма так долго открывается из-за чего то другого. Например, влияния условного оформления или набора картинок значений в динамическом списке или вообще чего-то другого.
Для того, чтобы исключить все возможные гипотезы с неоптимальным кодом и модификациями форм, создадим простую внешнюю обработку, которая будет содержать только динамический список.
Пробуем ее запустить вместе с замером производительности. И тут начинается самое интересное: вроде кода нет, но почему тогда форма снова открывается так долго. Давайте разбираться.
Для этого настроим сбор технологического журнала по событиям CALL и SDBL:
Таким образом, технологическая платформа для получении дерева элементов выполняет запросы уточнения всей иерархии на вложенность в справочнике и сумма выполнения данных запросов занимает все указанное время.
Стоит отметить, что справочник «Структурные единицы» является иерархическим, с иерархией элементов.
Данная технология не является новой и применяется в других типовых решениях. Например, в «малоизвестном» продукте «1С:ERP Управление предприятием 2» справочник «Партнеры» также имеет иерархию элементов и при этом работает очень быстро. Если мы заглянем на его форму списка, то увидим лишь одно явное отличие: свойство отображение таблицы в справочнике «Партнеры» стоит «Иерархический список», а в «Структурные единицы» — Дерево.
Делаем предположение, что причиной является этот переключатель. Устанавливаем его в значение в «Иерархический список» и повторяем эксперимент. В результате получаем открытие формы за 3 секунды. А установив значение «Список» форма открылась меньше чем за одну секунду. Повторив сбор технологического журнала мы пришли к выводу, что для отображении иерархии платформа формирует запросы для каждого отображаемого элемента. При этом если элемент вложенный и ветка не раскрыта, то данные по нему получены не будут, что и влияет на скорость отображения.
Выбирать подразделения или склады не осознавая структуры предприятия очень тяжело. Особенно, если название элементов совпадает. Потому мы приняли решение сохранить отображение деревом. Для этого мы добавили честный реквизит с типом «Дерево» и повторили отображаемые колонки.
Для заполнения этого дерева мы сначала выполняем запрос повторяющий текст запроса динамического списка, а затем пользуемся механизмом схемы компоновки данных. Данный механизм позволяет сократить время на формирование иерархии, т. к. решает задачу иерархии не с помощью запросов к базе данных, а с помощью встроенного механизма компоновки данных.
Повторив эксперимент после модернизации получили время выполнения меньше одной секунды. Таким образом, использование динамических списков иерархических объектов и отображение в виде дерева может привести к большому количеству служебных запросов к базе данных и задержке при открытии, перемещении или поиске по таблице.