Elbuz сам надсилає клієнту лист чи SMS, змінює статус або створює документ, щойно з документом чи контрагентом щось сталося. Ви один раз задаєте подію, умову й команду — далі правило працює без вас.
Коли це знадобиться:
- Замовлення приїхало з сайту — клієнт одразу отримує лист-підтвердження.
- Рахунок не оплатили вчасно — нагадування йде щодня, поки не проставлено дату оплати.
- Менеджер перевів замовлення в потрібний статус — клієнт отримує SMS саме в цей момент.
- Замовлення дійшло до відвантаження — витратна накладна з тими самими позиціями створюється сама.
З чого почати: перше правило за сім кроків — список документів → меню в шапці → «Автоматичні правила».
Розмова з підтримкою — замість читати: навіщо це потрібно, що налаштувати і що ви отримаєте.
Що вміють автоматичні правила
Правило складається з події, умови й команди. Кожну частину розібрано окремою статтею.
- Дванадцять подій — правило чекає створення, збереження чи проведення документа, змін контрагента або простроченої оплати.
- Умова з конструктора — правило відсіює записи за полями вашого списку і може реагувати саме на зміну статусу.
- Одинадцять команд — лист, SMS, завдання, новий документ чи контрагент, зміна полів, HTTP-запит, запуск процесу.
- Формули у значеннях полів — значення, яке програма рахує сама для кожного запису.
- Захист від повторів — команда спрацьовує по запису один раз або не частіше за заданий період.
- Перевірка й журнал — схема правил із попередженнями, рядок у «Журналі операцій» на кожну команду, прибирання наслідків.
Де це і хто має доступ
Пункту меню в цього вікна немає, ярлика на робочому столі теж. Воно відкривається тільки з шапки того списку, для якого ви заводите правила, і від цього залежить, які події вам запропонують: із документів видно події документів, із контрагентів — події контрагентів.
- Зі списку документів
- меню в шапці → «Автоматичні правила»
- Зі списку контрагентів
- меню в шапці → «Автоматичні правила» (вікно «Тригери (події системи, умови та дії)»)
- Шаблони повідомлень
- кнопка-лампочка в шапці — правило звідси виходить без умови (див. нижче)
- Право доступу
- вікно «Автоматичні правила»; окремо — додавання, видалення, редагування
- Підготувати
- поштову скриньку для листів; увімкнений системний розклад для простроченої оплати
1
Автоматичні правила- «Автоматичні правила» — єдиний вхід у налаштування тригерів для документів.
У самому списку правил три колонки правляться без відкриття картки: «Активність», «Назва» і «Порядок виконання». Подвійний клік по клітинці — і зміна йде в базу відразу, без кнопки збереження. Решта колонок теж відкриваються на правку, але не зберігаються: після оновлення вікна в них знову буде старе значення.
Правило, створене з вікна «Шаблони повідомлень», виходить без умови — і тому спрацьовує на кожен запис підряд.
Звідти вікно відкривається без прив’язки до документів чи контрагентів, а список полів умови береться саме від неї: конструктор у такому правилі порожній, збирати умову нема з чого.
Саму подію програма розбере — тип запису вона визначає з того, що з подією приїхало, — але відсіювати зайве буде нічим. Заводьте правила зі списку документів або зі списку контрагентів — там конструктор умови бачить поля вашого списку.
Право на вікно відкриває усі правила акаунта, а не тільки свої: відбору за автором у списку немає. Зняті галочки «додавання», «видалення» чи «редагування» прибирають відповідну кнопку з шапки або олівець із сітки, а не показують помилку. «Схема правил», картка правила й налаштування команди окремого права не мають — перевірка стоїть на списку. Детальніше: права доступу.
Як це працює
Правило складається з трьох частин, і кожна відповідає на своє питання. Подія — коли перевіряти. Умова — чи цей запис нас цікавить. Команда — що зробити. Команд у правила може бути кілька, вони виконуються по черзі за полем «Порядок виконання».
- Дія або результат
- Розвилка: далі шлях залежить від відповіді
1
Подія2
Період перевірки3
Активність- Подія обирається один раз при створенні правила і потім не змінюється.
- «Період перевірки» = 0 означає «один раз на запис і більше ніколи».
- Тумблер «Активність» — тут вимкнений: обидва правила в акаунті вимкнено.
Головне, що варто засвоїти одразу: команди виконуються синхронно, у тому самому запиті, який зберіг запис. Ніякої черги, ніякої затримки. Натиснули «Зберегти» в картці замовлення — лист пішов до того, як вікно закрилося. Виняток один: команда «Запустити процес (Flow)» створює фоновий прогін і не чекає його завершення.
Друге: подія піднімається на будь-яке збереження запису, звідки б воно не йшло — з картки, зі списку, з імпорту, з інтеграції по API, з крону, з іншого правила. Тригер не розрізняє «людина натиснула кнопку» і «файл завантажився».
Розклад і тригери — два різні механізми. Розклад відповідає на питання «коли почати» і дивиться на годинник; тригер дивиться на дані й спрацьовує від того, що з ними зробили.
Спільного в них рівно два місця: системний розклад, який раз на 32 хвилини перевіряє документи (про нього), і «Журнал операцій», куди обидва пишуть результат. Про запуск за часом — окрема стаття про розклад і чергу завдань.
Перше правило за сім кроків
Правило «лист клієнту при новому замовленні»
Сценарії
Кожен сценарій варто спершу перевірити на одному записі з вузькою умовою — як описано в розділі про масове спрацювання.
Лист-підтвердження на кожне нове замовлення
Задача: клієнт отримує лист, коли його замовлення приїхало в програму з сайту.
- Подія: «Документ: додавання».
- Умова: «Тип документа» дорівнює «Замовлення покупця».
- Команда: «Надіслати листа» із заповненим шаблоном.
- «Період перевірки»: 0.
Що вийде: лист іде наприкінці того самого завантаження замовлень із сайту, яке створило замовлення. Замовлення, додане вручну зі списку документів, листа не отримає: подія створення, яку піднімає ручне додавання, не несе номера документа, і правило такий запис пропускає.
Подальші збереження замовлення листа не надсилають: «Документ: додавання» по одному замовленню піднімається один раз. З тієї ж причини лист, який не пішов — немає поштової скриньки або порожній отримувач, — сам не повториться: у «Журналі операцій» буде «Не виконано!», а нової події додавання для цього замовлення вже не буде.
Нагадування про неоплачений рахунок, поки його не оплатять
Задача: клієнт, який не оплатив до строку, отримує нагадування, і нагадування повторюється, поки оплата не надійде.
- Подія: «Документ: прострочено оплату». Умову-зразок «Оплатити до» менше
{current_date}програма підставить сама; щоб писати лише після трьох днів прострочки, замініть значення на{current_date-3day}. - Команда: «Надіслати листа».
- «Період перевірки»: 1, «Одиниця виміру» — днів.
Що вийде: раз на 32 хвилини системний розклад бере документи, у яких «Оплатити до» минуло не більше ніж 90 днів тому, а дата оплати не проставлена, — до 300 найновіших за прогін, — і правило надсилає по них лист.
Повтор рахується від часу листа: запис журналу стирається, коли минула доба з моменту надсилання. Тому лист, надісланий у понеділок, повториться у вівторок, у перший прогін розкладу після того, як мине 24 години.
Чого не станеться: документ із проставленою датою оплати з відбору випадає, і нагадування по ньому припиняються. Так само вони припиняються, коли від «Оплатити до» минуло понад 90 днів. Якщо рядок системного розкладу в акаунті вимкнений, не піде жодного листа.
SMS, коли замовлення перейшло в потрібний статус
Задача: клієнт отримує SMS саме в момент, коли менеджер переводить замовлення в певний статус, а не при кожному збереженні картки.
- Подія: «Документ: оновлення».
- Умова: «Статус документа» не дорівнює «Початкове значення» і «Статус документа» дорівнює потрібному статусу.
- Команда: «Надіслати SMS».
- «Період перевірки»: 0.
Що вийде: SMS іде, коли статус змінили на потрібний і зберегли документ. Збереження без зміни статусу SMS не надсилає. Якщо статус пішов в інший і потім повернувся, SMS піде ще раз: при зміні поля журнал спрацювань для цього документа очищається.
Системний розклад теж піднімає «Документ: оновлення» — для непроведених документів за останні 30 днів, і робить це без стану документа «до збереження». Для таких перевірок на місце «Початкового значення» підставляється поточний статус, тож «статус не дорівнює Початковому значенню» не виконується, і розклад SMS не надсилає. Повідомлення йде лише тоді, коли статус справді змінили під час збереження документа.
Витратна накладна із замовлення без ручного копіювання
Задача: коли замовлення доходить до статусу відвантаження, на нього створюється витратна накладна з тими самими позиціями.
- Подія: «Документ: оновлення».
- Умова: «Тип документа» дорівнює «Замовлення покупця» і «Статус документа» дорівнює статусу, з якого ви відвантажуєте.
- Команда: «Створити документ»: у полі типу документа — «Витратна накладна»; якщо накладну треба ще й провести — поле проводки зі значенням 1.
- «Період перевірки»: 0.
Що вийде: програма створює копію замовлення в типі «Витратна накладна» з усіма позиціями, повʼязану із замовленням, з номером за форматом цього типу. Якщо задано проводку, накладна проводиться й рухає склад так само, як при ручному проведенні (про залишки). По одному замовленню накладна створюється один раз: наступні збереження замовлення другої копії не дадуть.
Чого не станеться: без поля типу документа нічого не створюється — у «Журналі операцій» буде «Не виконано!».
Часті запитання
Коли саме виконується команда — одразу чи потім?
Одразу, у тому самому запиті, який зберіг запис. Виняток один — команда «Запустити процес (Flow)»: вона створює фоновий прогін і не чекає його завершення.
Чому правило спрацювало один раз і більше не спрацьовує?
Програма запамʼятовує кожну пару «команда + запис» і вдруге команду не виконує. Щоб дозволити повтор, поставте «Період перевірки» більше нуля або додайте в умову пункт «Початкове значення» (про повтори).
Що буде, якщо на одну подію підходять кілька правил?
Спрацюють усі, по черзі, у порядку поля «Порядок виконання», а при однаковому порядку — за назвою. Зупинити наступні правила перше не може.
Чи спрацює правило на документи, які приїхали з імпорту або з сайту?
Так. Подія піднімається на кожен збережений запис незалежно від того, хто його зберіг: людина, імпорт, інтеграція по API чи інше правило.
Чи можна запускати правило за часом, наприклад щодня о третій?
Ні, правило чекає зміни даних. Запуск за часом — це розклад і черга завдань. Виняток — прострочені оплати й непроведені документи: їх раз на 32 хвилини обходить системний розклад.
Чи можна повісити правило на товар, прайс чи категорію?
Ні. Усі дванадцять подій стосуються документів і контрагентів, подій для товарів, прайсів і категорій немає.
Чи можна скасувати те, що правило вже зробило?
Ні. Надісланий лист, проведений документ і змінений запис назад не відкотяться. Тому нове правило спершу перевіряють на одному записі з якнайвужчою умовою.
Суміжні теми
- Якщо дію треба запускати за часом, а не за зміною даних, — розклад і черга завдань.
- Якщо автоматизація потрібна для угод і задач менеджерів у CRM, — автоматизації CRM.
- Якщо правила мають бачити не всі співробітники, — права доступу.
- Якщо умову будуєте за статусами й полями замовлення, — замовлення покупця.