Задачи
Срок в зависимости от приоритета
Из Категории А в Категорию Б автоматически ставится подзадача. При постановке подзадачи в ней устанавливается срок: если у задачи А высокий приоритет, то у задачи Б срок будет +1 рабочий день с момента постановки; если обычный – 3 рабочих дня; если низкий – 2 недели. В задаче используются "Категория А" и "Категория Б". Пользователь ставит задачу в "Категории А", а подзадача должна автоматически создаваться в "Категории Б". Поэтому все smart-выражения надо создавать в "Категории А", но в пакете действий в качестве категории постановки выбрать "Категорию Б". Напоминаем, что в "Первой Форме" приоритеты имеют численные эквиваленты: низкий приоритет — 0; обычный — 1; высокий — 3. 1 способ решения Для реализации данного кейса необходимо выполнить три аналогичных последовательности операций по привязке пакетов действий к событию. Ниже рассматривается только один цикл — создание подзадачи для задачи с низким приоритетом. Аналогичным образом нужно создать привязки пакетов действий к событиям для задач с высоким и обычным приоритетами. В блоке привязки пакетов действий к событиям создайте пакет, привязанный к событию "После постановки задачи". Если smart-фильтр вернул true, то должен выполняться пакет действий "Срок (приоритет род задачи — низкий)" с единственным действием "Создать задачу". При помощи smart-выражения необходимо к сроку добавить 2 недели (т.е. 14 дней).
Создание подзадачи для задачи с низким приоритетом 2 способ решения 1. В блоке привязки пакетов действий к событиям создайте пакет, привязанный к событию "После постановки задачи". Пакет содержит единственное действие "Создать задачу". Значение поля "Срок" установите с помощью smart-выражения, в котором рассматриваются все три варианта значений поля "Приоритет". Обратите внимание, что для добавления календарных и рабочих дней используются разные функции.
Создание подзадачи для задачи с любым приоритетом |
Проверка проектов на готовность к закрытию
В категории "Проекты" настроен ДП "Дата закрытия". Каждый месяц 20 числа все проекты из этой категории проверяются на готовность к закрытию: закрывать можно проекты, находящиеся в статусе "Подготовка к закрытию" и у которых месяц даты закрытия совпадает с текущим месяцем. Для закрытия каждого проекта ставится отдельная подзадача в категории "Закрытие проектов" со сроком "Дата закрытия + 3 дня". Так как действие нужно выполнять каждый месяц, настройте smart-расписание в категории "Проекты". Заполните параметры расписания: ежемесячно, 20 число каждого 1 месяца; продолжительность повторения — без ограничений. В фильтре для отбора проектов на закрытие для проверки статуса используйте возможность выбора ID объекта вместо конкретного ID статуса.
Настройка расписания для закрытия проектов |
Ежемесячная проверка превышения сроков задач
Есть категория, для которой назначен куратор. В последний день каждого месяца ко всем завершенным задачам в этой категории, выполнявшимся больше 10 рабочих дней, подписывается куратор с уведомлением "По данной задаче был превышен максимальный срок в 10 дней". Т.к событие нужно вызывать каждый месяц, то необходимо составить smart-расписание. В нужной категории создайте новое smart-расписание c параметрами: Ежемесячно, каждую последнюю пятницу (считаем, что это последний рабочий день месяца); продолжительность повторения: без ограничений.
Настройка расписания для отправки уведомлений куратору Для смарт-фильтра, отбирающего завершенные задачи со сроком выполнения более 10 раб. дней, возможен и друой вариант. В этом случае проверяется, что задача была именно завершена, а не отклонена. Для проверки статуса используйте возможность выбора ID объекта вместо конкретного ID статуса.
Проверка завершенных задач со сроком выполнения более 10 дней |
Обработка заявок в техподдержку
Категория "Заявки" предназначена для регистрации обращений в службу техподдержки, а категория "Типы обращений" — это справочник типов обращений. В этом справочнике для каждого типа обращения указан исполнитель и максимальное время устранения проблемы. В Категории "Заявки" есть ДП "Тип обращения" (Lookup), указывающий на соответствующий справочник. При создании нового обращения пользователь описывает суть проблемы и выбирает из справочника подходящий тип обращения. Поля "Исполнитель" и "Срок" в форме создания нового обращения не отображаются — их значения формируются автоматически при регистрации обращения, на основании соответствующих параметров из выбранной записи справочника. Для того, чтобы после постановки задачи в Категории "Заявки" заполнялись параметры "Срок" и "Исполнитель", необходимо создать привязку пакета действий к событию "После постановки задачи". Смарт-фильтр проверяет, выбрана ли запись справочника, то есть заполнен ли ДП "Тип обращения" (можно обойтись и без фильтра, сделав этот ДП обязательным при создании задачи в настройках ДП в категории).
Настройка пакета действий при регистрации обращения В пакете должны быть два действия: Изменить срок и Добавить исполнителя. Исполнитель и срок назначаются при помощи smart-выражений, которые обращаются к записи справочника, указанного в ДП "Тип обращения".
Настройка смарт-действий для назначения исполнителя и срока обращения. Кликните мышью для просмотра изображения в полном размере |
Проверка прав исполнителей и подписчиков
В Категории А при постановке задачи назначается исполнитель и добавляются подписчики. При этом есть необходимость запретить менять исполнителя, запретить добавлять других подписчиков, а также запретить кому-либо кроме исполнителя осуществлять переходы по маршруту. В данном случае нужно создать три привязки пакетов действий к событиям, так как есть необходимость проверки событий "Перед назначением исполнителя", "Перед назначением подписчика" и "Перед переходом". Три привязки смарт-пакетов к событиям Привязка действий к событию 1 запрещает менять\добавлять исполнителя.
Отмена назначения исполнителя Привязка действий к событию 2 запрещает добавлять подписчика. Настройки аналогичны предыдущему пункту, но проверяется наличие подписчиков, а не исполнителей. Подписчики у задачи появятся в момент постановки задачи, т.к. заказчик и исполнители всегда становятся подписчиками (если заказчик пользователь, а не служебный робот). Привязка действий к событию 3 запрещает всем, кроме исполнителя, осуществлять переход.
Отмена перехода |
В Категории "Запросы" при переходе задачи из статуса с "Новая" в статус "Принято" должен формироваться комментарий с сообщением: "Ваш запрос зарегистрирован. Регистрационный номер запроса № (НОМЕР ЗАДАЧИ) от дд.мм.гг. (ДАТА начала работ). Назначен Исполнитель (ФИО)". Создайте пакет с единственным действием "Отправить комментарий" и привяжите его к действию "Выполнить переход", выбрав переход "Новая — Выполняется".
Настройка отправки комментария Текст комментария может быть сформирован как с указанием ответственного исполнителя (см. выше), так и с указанием любого из исполнителей.
Другой вариант формирования текст комментария |
Проверка уникальности записи справочника
Есть категория-справочник "Контрагенты". Каждый контрагент имеет уникальный код, который хранится в соответствующем ДП. При постановке задачи надо проверять, существует ли контрагент c задаваемым кодом, если есть – отменять постановку задачи. Создайте пакет действий для события "Перед постановкой задачи". Пакет должен содержать единственное действие "и". Условие выполнения пакета определяется смарт-фильтром, в котором проверяется наличие контрагента с таким же кодом.
Отмена создания повторяющейся записи |
В категории А есть таблица "Сводная ведомость", которая содержит два столбца — "Наименование" (текстовый) и "Сумма" (денежный). Под таблицей располагается поле "Итого", которое содержит сумму значений столбца "Сумма" по всем строкам таблицы. При изменении значений в таблице автоматически пересчитывается итоговая сумма. Для события "После смены ДП" создайте пакет с единственным действием "Изменить значение ДП". В нем рассчитывается и заполняется итоговая сумма (ДП "Итого") по колонке таблицы "Сводная ведомость" (ID колонки "Сумма" равен 172). Значение параметра рассчитывается при помощи smart-выражения, часть которого представляет собой запрос TSQL.
Расчет итоговой суммы по колонке таблицы |
Итоговые значения для блока "Используется"
В категории "Договоры" регистрируются заключенные договоры, а в категории "Фактические приходы" — платежи по этим договорам. Для связи между этими двумя категориями используется lookup-поле "Договор контрагента". Сумма поступившего платежа хранится в категории "Фактические приходы" в ДП "Сумма платежа". В категории "Договоры" настроен блок "Используется", в котором на вкладке "Поступления" отображаются все записи из категории "Фактические приходы", относящиеся к данному договору. Итоговый ДП "Сумма фактических приходов" должен формироваться как общая сумма по колонке "Сумма платежа" (кроме приходов, находящихся в статусе "Отменен"). Разместите рядом с блоком "Используется" ДП с итоговой суммой, которая будет рассчитываться с помощью смартов.
Итоговый ДП для блока "Используется" Создайте пакет действий и настройте в нем действие "Изменить значение ДП". Смарт-выражение должно суммировать все приходы по нужному договору (кроме задач, находящихся в статусе "Отменен"). Привяжите этот пакет действий к событиям "После постановки задачи" и "После смены статуса (в т.ч. принудительно)".
Подсчета итоговой суммы фактических приходов |
Проверка статуса сопутствующих договоров
Для завершения сделки определенного типа необходимо согласовать все сопутствующие договоры (предположим, что все такие договоры создается автоматически при создании сделки). Связь между сделкой и договорами осуществляется через ДП "Родительский договор" (типа Lookup). Необходимо настроить автоматизацию, которая не позволяла бы перевести сделку в следующий статус, пока не все договоры согласованы. В категории "Сделки" к событию "Перед переходом" в определенный статус (например, в статус "Завершена") привяжите пакет с единственным действием "Отменить". Пакет выполняется, если соблюдается условие смарт-фильтра, в котором проверяются задачи в категории "Согласование договора", связанные с данной сделкой (т.е. у которых в ДП "Родительский договор" указана ссылка на исходную задачу) и находящиеся в статусе "Согласовано". Таким образом, если на момент перехода для данной сделки не все договоры находятся в нужном статусе, то переход не совершается и выдается соответствующее предупреждение.
Проверка согласования договоров |
Объединение нескольких элементов списка в строку
Организация-контрагент отказывает различные виды услуг. В справочнике контрагентов, в карточке задачи, эти услуги хранятся в ДП "Выбор нескольких задач из категории". При заключении договора с этой организацией необходимо создать задачу, в тексте которой все выбранные услуги перечислены одной строкой. При изменении списка услуг строка должна обновляться. Для этого необходимо собрать в один текстовый ДП значения из нескольких элементов массива (перечислить их, разделяя пробелами). Например, список услуг (ДП "Выбор нескольких задач из категории") содержит значения:
Список услуг В итоге должна получиться строка:
Результирующая строка Создайте пакет действий на событие "После смены ДП", и в этом пакете объедините все значения списка в одну строку с помощью смарт-функции конкатенации. Обратите внимание, что в категории-справочнике услуг в тексте задач должны быть отключены html-теги, иначе при конкатенации они попадут в итоговую строку.
Изменение буферной строки |
Отдельные пользователи заинтересованы в том, чтобы контролировать изменение одного или нескольких ДП в Категории А. Список заинтересованных пользователей хранится в категории "Контролеры", в ДП "Подписчики" (типа "Выбор пользователей"). В Категории А для каждого из ДП, изменения которого необходимо контролировать, создайте пакет действий, привязанный к событию "После смены ДП". Пакет действий содержит одно действие "Добавить подписчика". Как только значение этого ДП изменится, пользователи из ДП "Подписчики" в категории "Контролеры" будут добавлены в качестве подписчиков в Категорию А, а значит, будут получать уведомления об изменении ДП.
Добавление подписчика Вместо действия "Добавить подписчика" можно использовать действие "Отправить комментарий". В этом случае то же самое смарт-выражение можно использовать для формирования значения параметра "Получатели (пользователи)".
Отправка комментария с одновременным добавлением адресатов в подписчики |
Создание плановых платежей к договору
Договор с клиентом предусматривает поэтапную оплату. Для этого в категории "Договоры" есть ДП "График платежей" типа "Таблица" со столбцами: "Назначение платежа" (текст), "Дата платежа" (дата) и "Сумма платежа" (деньги). После перехода договора в статус "Согласован" в категории "Плановые платежи" создаются подзадачи — по одной подзадаче для каждой строки таблицы "График платежей". В категории "Договоры" для события "После перехода" в статус "Согласован" создайте пакет с единственным действием "Создать задачу". Поскольку действия должны быть выполнены столько раз, сколько строк содержит ДП "График платежей", пакет должен быть циклическим. Смарт-выражения для определения даты и суммы очередного платежа аналогичны смарт-выражению для определения назначения очередного платежа, меняется только ID колонки.
Добавление подписчика |
Создание задачи с договором по итогам согласования
Согласование договора с контрагентом ведется в категории "Согласование договоров". В этой категории есть ДП "Договор с контрагентом". После завершения процесса согласования создается новая задача в категории "Договоры", и ссылка на нее записывается в ДП "Договор с контрагентом". В категории "Согласование договоров" создайте пакет действий, привязанный к событию "После перехода" для перехода "Подготовка договора-Договор согласован". Пакет действий содержит два действия: "Создать задачу" в категории "Договоры" и "Изменить значение ДП", где ID этой задачи записывается в ДП "Договор с контрагентом". ID только что созданной задачи передается между действиями одного пакета как значение переменной.
Привязка пакета к событию согласования договора
Создание задачи-договора
Ссылка на задачу записывается в ДП |
Бизнес-кейсы
Назначение исполнителя в зависимости от набора условий
Среди сотрудников юридического отдела поддерживается специализация: договоры по определенной тематике передаются на проверку определенному юристу. Все задачи, поступающие в отдел, автоматически распределяются между юристами в зависимости набора условий, которые описываются в отдельном справочнике. Необходимо настроить автоматизацию таким образом, что на каждое возможное сочетание условий назначается определенный сотрудник или группа сотрудников юридического отдела и отводится определенный срок на выполнение задачи. 1. Создайте справочник "Распределение полномочий юристов". В нем должны быть следующие ДП:
2. В категории "Согласование договоров", содержащей задачи для юридического отдела, создайте следующие ДП (соответствующие аналогичным ДП в справочнике из п.1):
3. Настройте смарт-автоматизацию в категории "Согласование договоров". 3.1. Выбор исполнителей:  Выбор исполнителей 3.2. Установка срока:  Установка срока |
Нумерация входящих и исходящих документов
При регистрации входящих и исходящих документов необходимо обеспечить сквозную нумерацию. При этом более ранние документы должны иметь меньшие номера. Для обеспечения сквозной нумерации используйте эмулятор нумератора — специально созданный ДП, в котором ведется учет номеров задач в категории. Эмулятор нумератора может быть полезен в следующих случаях: •Иногда по некоторым причинам документ сразу не может быть зарегистрирован в системе, но в дальнейшем регистрировать его придется "задним числом", поэтому для него надо заранее зарезервировать номер. В списке задач категории или на форме создания новой задачи настраивается кнопка "Зарезервировать номер". По нажатию на нее создается задача в специальном статусе "Зарезервировано". Никакие данные в нее не записываются (кроме значения ДП, эмулирующего нумератор). В дальнейшем когда нужные документы придут и их необходимо будет зарегистрировать в системе, пользователь сможет найти задачу с нужным номером в статусе "Зарезервировано", перевести ее в обычный статус (в соответствии с настроенным маршрутом) и продолжить работу в обычном режиме. •С помощью такого эмулятора можно вести сложную нумерацию, включающую проверку дополнительных условий (например, приказы регистрируются с различными типами номеров в зависимости от вида приказа). •Если один из прошлых документов по каким-то причинам удаляется из системы, то создать новый документ под этим номером эмулятор уже не даст. Эмуляторы могут быть двух типов: 1. При создании новой задачи с помощью смарта проверяется максимальное значение ДП, который хранит номера, среди всех задач данной категории, и к этому значению прибавляется 1. 2. При создании новой задачи подсчитывается число задач данной категории, и к этому значению прибавляется 1. Такой эмулятор может применяться не всегда, поскольку правильность нумерации нарушается при удалении задач. Пример эмулятора нумератора по максимальному значению ДП для категории "Приказы". Генерирует уникальные значения для документов в течение года, с нового года нумерация начинается заново с 1.
Генерация номера по максимальному значению ДП Пример эмулятора нумератора по числу задач в категории "Входящая корреспонденция" для документов в статусах, отличных от "Проект документа" и "Не регистрировать" (ID этих исключаемых из нумерации статусов равны 1 и 2).
Генерация уникального номера по числу задач в категории |
От разных подразделений поступают запросы на выдачу денежных средств. Эти запросы фиксируются в категории "Запросы на выдачу ДС" (каждый запрос — в отдельной задаче). В запросе указываются необходимая (плановая) сумма и фактически выделенная сумма. Финансовая служба время от времени выделяет определенные объемы денежных средств, которые затем необходимо распределить по поступившим ранее запросам. Задачи на распределение фиксируются в категории "Распределение ДС". В задаче на распределение автоматически формируется таблица, содержащая список поступивших запросов и запрошенные суммы. В отдельной колонке таблицы сотрудник финансовой службы указывает фактически выделяемые суммы. После подтверждения платежа фактические выделенные суммы проставляются в соответствующих запросах. Необходимо настроить автоматическое формирование таблицы и автоматическое разнесение выделенных сумм по запросам. 1. В категории "Запросы на выдачу ДС" создайте четыре ДП:
2. В категории "Распределение ДС" создайте два ДП:
3. В категории "Распределение ДС" настройте смарт-автоматизацию: 3.1. На событие "После постановки задачи" В ДП "Буферный" последовательно передаются все подходящие задачи из категории "Запросы на выдачу ДС":
Отбор подходящих задач Во всех отобранных задачах из категории "Запросы на выдачу ДС" в ДП "Выдача ДС" прописывается ссылка на текущую задачу. 3.2. На событие "При изменении ДП" для ДП "Буферный" Изменить значение ДП "Таблица", добавив в нее данные из задачи, на которую ссылается ДП "Буферный" (в формате json)
Обновление таблицы ДП "Буферный" поменяет свое значение столько раз, сколько подходящих задач будет отобрано (в п.3.1). Столько же раз отработает смарт-действие "При изменении ДП" (п.3.2), а значит, столько же строк будет добавлено в таблицу. 4. После того, как таблица сформирована и пользователь внес необходимые изменения в колонке "Факт", необходимо вернуть исправленные данные в соответствующие запросы на выдачу ДС. Для этого на форме задачи в категории "Распределение ДС" создайте кнопку "Подтвердить платеж", которая будет отвечать за выполнение фиктивного перехода, и настройте автоматизацию: 4.1. В категории "Распределение ДС" при выполнении фиктивного перехода "Подтвердить платеж" во всех запросах из таблицы изменить значение ДП "Триггер" (например, с 1 на 0) 4.2. В категории "Запросы на получение ДС" для события "При изменении ДП" для ДП "Триггер" создайте смарт-действие, которое получит данные о фактически выданных средствах из соответствующей строки таблицы в задаче из ДП "Выдача ДС" и запишет скорректированные данные в ДП "Выдано":
Корректировка данных |
Сопоставление плановых и фактических платежей
В категории "Договоры" регистрируются заключенные договоры. Категории "Плановые платежи" и "Фактические платежи" связаны с ней с помощью ДП "Договор" (типа Lookup). Распределение очередного фактического платежа между плановыми осуществляется итерационно:  Схема распределения платежей В категории "Плановые платежи" есть следующие ДП: •"Сумма план" — сумма планового платежа; •"Таблица оплаты" — таблица, в которую записываются фактические платежи, закрывающие его. В таблице есть две колонки: "Сумма оплаты" и "Дата поступления оплаты"; •"Сумма факт" — сумма всех поступивших на текущий момент фактических платежей, закрывающих данных платеж. Этот ДП рассчитывается как итоговая сумма по всем строкам таблицы; •"Остаток" — рассчитывается как "Сумма план"-"Сумма факт". Вся автоматизация по распределению поступивших платежей реализуется в категории "Фактические платежи". Список всех пакетов в привязке к событиям: Список настроенных в категории смартов 1. Создайте в категории "Фактические платежи" три вспомогательных ДП: •"Плановый платеж" (lookup) — в этот ДП на каждой итерации цикла распределения записывается ссылка на очередной плановый платеж; •"Остаток" (число) — в этот ДП на каждой итерации цикла распределения загружается неоплаченный остаток по очередному плановому платежу; по умолчанию (т.е. на момент создания задачи) этот ДП равен 0; •"Нераспределенный остаток" (число) — в этот ДП на каждой итерации цикла распределения записывается остаток от фактического платежа, еще не распределенный к текущему моменту между плановыми платежами. 2. Подготовка к запуску цикла распределения. 2.1. Подготовьте начальное значение ДП "Нераспределенный остаток". На начало первой итерации цикла распределения он должен быть равен полной сумме поступившего фактического платежа. Настройте пакет из единственного смарт-действия, в котором будет заполняться этот ДП, и привяжите его к событию "После постановки задачи":
Заполнение ДП "Нераспределенный остаток". Кликните мышью для просмотра изображения в полном размере 2.2. Подготовьте начальные значения ДП "Плановый платеж" и "Остаток". Для этого настройте еще один пакет из двух смарт-действий и также привяжите его к событию "После постановки задачи". В качестве смарт-фильтра используйте выражение, которое определяет, есть ли незакрытые плановые платежи по этому договору:
Смарт-фильтр для определения незакрытого платежа по договору Первое действие пакета записывает в ДП "Плановый платеж" ссылку на первый (самый ранний) плановый платеж.
Запись в первый плановый платеж. Кликните мышью для просмотра изображения в полном размере Второе действие записывает в ДП "Остаток" сумму из этого планового платежа.
Запись остатка 3. Итерация цикла распределения заключается в следующем: очередной плановый платеж закрывается исходя из значения текущего нераспределенного остатка, а затем сам нераспределенный остаток уменьшается на списанную сумму. Событием, запускающим очередную итерацию цикла, является очередное изменение ДП "Остаток". Создайте два пакета, привязанных к событию "После смены ДП" для ДП "Остаток". 3.1. Первый пакет состоит из единственного действия, которое записывает данные о поступивших средствах в новую строку таблицы платежей в текущем плановом платеже (который "закрывается" на данной итерации).
Запись остатка 3.2. Второй пакет рассчитывает нераспределенный остаток после закрытия текущего планового платежа. Он тоже состоит из единственного действия:
Расчет нераспределенного остатка 4. Финальные проверки. Изменение ДП "Нераспределенный остаток" инициирует выполнение еще двух пакетов действий, которые привязаны к событию изменения этого ДП. Эти пакеты определяют, является ли эта итерация последней или нет, и в зависимости от этого выполняют переход на следующую итерацию цикла или подведение итогового нераспределенного остатка (на последней итерации). 4.1. Первый пакет срабатывает, если еще остался нераспределенный остаток и остались незакрытые плановые платежи, то есть цикл нужно продолжать. Условие смарт-фильтра выглядит так:  Проверка наличия нераспределенного остатка Пакет состоит из двух действий. Первое действие записывает в ДП "Плановый платеж" ссылку на очередной плановый платеж (выражение "План платеж с ближайшим сроком" уже использовалось на шаге 2.2).  Ссылка на очередной платеж Второе действие записывает в ДП "Остаток" неоплаченный остаток из этого планового платежа.  Расчет неоплаченного остатка планового платежа Изменение ДП "Остаток" снова запускает пакеты, определенные на шаге 3, т.е. начинает очередную итерацию цикла. 4.2. Второй пакет срабатывает, если еще остался нераспределенный остаток, но незакрытых плановых платежей уже не осталось, то есть цикл нужно прекращать. Такая ситуация может возникнуть, если клиент оплатил большую сумму, чем было запланировано. Условие смарт-фильтра выглядит так:
Смарт-фильтр для наличия нераспределеного остатка при отсутствии незакрытых плановых платежей Сам пакет состоит из трех действий. Первое действие записывает в ДП "Плановый платеж" ссылку на последний закрытый плановый платеж.
Ссылка на последний закрытый плановый платеж Второе действие записывает в этот последний платеж в таблицу поступивших оплат строку с переплатой, равной нераспределенному остатку.
Запись строки с переплатой Третье действие обнуляет оставшийся нераспределенный остаток.  Обнуление остатка |
Почтовые смарты
Постановка задач из электронной почты
Для подразделения выделен общий почтовый ящик crm@1forma.ru. Если на него приходит письмо, в теме которого содержится слово "Заявка", создается задача в категории "Входящие заявки". Заказчик задачи — или отправитель письма (если он пользователь системы — например, один из уже существующих клиентов отправляет новую заявку), или служебный пользователь Systemrobot. Если в адресатах письма есть не только ящик crm@1forma.ru, но и конкретный сотрудник, он назначается исполнителем. Если в письмо вложены файлы, они вкладываются в эту заявку. Для почтового ящика crm@1forma.ru настроен смарт-пакет со смарт-фильтром и двумя действиями: Создать задачу и Вложить файл. 1. Создать задачу 2. Вложить файл 3. Смарт-фильтр: Смарт-фильтр для почты |
