Что выбрать — БИ, Таблицу или Multilookup¶
Часто при проектировании бизнес-процесса и его реализации в "Первой Форме" встает вопрос — как лучше хранить связанную информацию, какую сущность лучше использовать для этого: ДП с возможностью множественного выбора (таблицу или multilookup) или отдельную категорию, на которую можно ссылаться через ДП Lookup.
Пример 1: компания регулярно проводит выставки и семинары для своих клиентов. Для подготовки создается задача в категории "Мероприятия", в этой задаче необходимо вести список приглашенных из числа контактных лиц клиентов.
Такой список можно реализовать:
-
в виде ДП Multilookup ("Выбор нескольких задач в категории"), содержащем ссылки на задачи категории "Контактные лица",
-
в виде ДП "Таблица", где каждая строка будет хранить данные о одном приглашенном,
-
создать отдельную категорию "Приглашения", где для каждого потенциального участника будет создаваться отдельная задача; а в категории "Мероприятие" сделать блок "Используется", настроенный на категорию "Приглашения".
Выбор способа реализации зависит от особенностей процесса.
Когда стоит использовать ДП Multilookup¶
Если для элемента важен только признак "выбран/не выбран" и никакие другие признаки не отслеживаются. Например, для сегментирования клиентской базы для каждого клиента указываются отрасли или сегменты рынка.
Когда стоит использовать ДП "Таблица"¶
Если для элемента важны дополнительные характеристики, кроме признака "выбран/не выбран". Например, при формировании заказа нужно вести список выбранных товарных позиций и для каждой позиции указывать количество. Другой пример — в карточке соискателя подсчитывается совокупный опыт работы по специальности.
Когда стоит использовать БИ¶
Если у элементов есть свой жизненный цикл, смена статусов. Например, для каждого участника нужно отслеживать статусы "Приглашен", "Принял приглашение", "Оплатил участие" и т.п. При переходе выполняется автоматизация (выставление счета и пр).
Если необходимо обеспечить разделение доступа к элементам. Например, каждый менеджер должен видеть только приглашенных из числа своих клиентов. Для задач такое разделение можно обеспечить с помощью смарт-доступа, а для строк таблицы или содержимого ДП — нельзя.
Если информацию нужно повторно использовать или отображать в разных частях системы. Например, с одной стороны -- в карточке мероприятия отображается список участников, с другой стороны -- в карточке клиента или контактного лица можно просматривать список мероприятий, в которых он участвовал, или список семинаров, к которым он проявил интерес (это можно учитывать при продажах). Организовать такие перекрестные ссылки удобнее всего с помощью задач и связей по ДП Lookup.
Пример 2 (используются все три способа):
По поручению центрального офиса торговой сети в магазинах регулярно проводятся рекламные акции. Для проведения очередной акции сотрудник центрального офиса создает задачу в категории "Подготовка рекламных акций". В этой задаче в ДП "Выбор нескольких задач в категории" он указывает магазины, которые будут участвовать в этой акции, и отправляет список на согласование.
После согласования списка с помощью автоматизации для каждого выбранного магазина ставится отдельная задача в категории "Поручения магазинам". Эти задачи связаны с исходной задачей с помощью ДП Lookup и отображаются в исходной задаче в блоке "Используется".
В каждой из задач для магазина заполняется ДП "Таблица", в которой последовательно отмечаются даты выполнения отдельных заданий (оформление витрин, раздача листовок и пр.).