Elbuz виконує команди правила лише тоді, коли сталася вибрана подія і запис підходить під умову. Подія відповідає на питання «коли перевіряти», умова — «чи цей запис нас цікавить».
Коли це знадобиться:
- Лист має йти тільки на замовлення покупця — умова за типом документа відсіє решту документів.
- Потрібна реакція на зміну статусу, а не на кожне збереження — пункт «Початкове значення» ловить саме зміну.
- Нагадувати про оплату через три дні після строку — підстановка дати в умові рахує строк сама.
- Нагадування має повторюватися щодня — «Період перевірки» дозволяє повтор по тому самому запису.
З чого почати: «Автоматичні правила» → «Додати» → вибрати подію.
Що вміють подія й умова
- Дванадцять подій — створення, збереження, проведення документа, зміни контрагента, підтвердження заявки AI-агента.
- Прострочена оплата — подія від системного розкладу раз на 32 хвилини, без дії людини.
- Конструктор умови — поле, оператор і значення з полів вашого списку документів чи контрагентів.
- Підстановки дат — «сьогодні мінус три дні» замість конкретної дати.
- «Початкове значення» — спрацювання саме на зміну поля.
- «Період перевірки» — один раз на запис або повтор не частіше за заданий строк.
Де це і хто має доступ
Пункту меню в правил немає: вікно відкривається зі списку документів чи контрагентів (усі входи).
- Подія
- «Автоматичні правила» → «Додати» → список подій
- Умова
- картка правила → секція «Умова»
- Право доступу
- вікно «Автоматичні правила» з правом редагування
Події, на які можна повісити правило
Подій дванадцять. Шість про контрагентів, пʼять про документи і одна про підтвердження заявки AI-агента.
| Подія у списку | Коли піднімається |
|---|---|
| Контрагент: додавання | створення картки контрагента |
| Контрагент: збереження | збереження картки контрагента |
| Контрагент: видалення | видалення контрагента — картка при цьому переїжджає в кошик і лишається доступною правилу |
| Контрагент : додавання | створення контрагента зовнішньою системою через API |
| Контрагент API: збереження | збереження контрагента через API |
| Контрагент API: видалення | видалення контрагента через API |
| Документ: додавання | створення документа, зокрема замовлення з сайту |
| Документ: оновлення | збереження документа; зміна замовлення під час завантаження (тунель, маркетплейси, API v2); плюс раз на 32 хвилини системний розклад обходить непроведені документи за останні 30 днів |
| Документ: видалення | рядок у списку є, але правило на нього не працює: до моменту перевірки документа вже немає в базі |
| Документ: проводка (підпис) | проведення документа і скасування проводки |
| Документ: прострочено оплату | тільки від системного розкладу, раз на 32 хвилини |
| AI-агент: підтвердження виконано | після того, як людина схвалила заявку AI-агента на зміну даних; ця подія пропонується тільки у вікні, відкритому з «Шаблонів повідомлень», — а звідти правило виходить без умови (чому) |
Прострочена оплата — окремий випадок
Ця подія не приходить від дії людини: її раз на 32 хвилини створює системний розклад. Він бере документи, у яких «Оплатити до» вже минуло, але не більше ніж 90 днів тому, і в яких не проставлена дата оплати — до 300 документів за прогін, починаючи з найновіших.
Тим самим прогоном розклад обходить непроведені документи за останні 30 днів — теж до 300 найновіших — і піднімає для них «Документ: оновлення».
Це рядок системного розкладу акаунта, заводити його не потрібно — він уже є. Але якщо розклад в акаунті вимкнений, подія не прийде взагалі: ні про прострочену оплату, ні про непроведені документи.
Коли ви створюєте правило саме на прострочену оплату, програма одразу підставляє в нього умову-зразок: «Оплатити до» менше {current_date}. Її можна залишити як є або переписати під себе.
Правило створюється вже ввімкненим. Це протилежно розкладу, який заводиться вимкненим і чекає, поки ви поставите галочку. Тому послідовність «створив правило → пішов пити каву → повернувся налаштовувати умову» небезпечна: правило без умови спрацьовує на кожну подію. Поки умова не готова, знімайте тумблер «Активність» у першій секції картки.
Умова: що саме перевіряється
Умова збирається конструктором: поле, оператор, значення — і так скільки завгодно рядків, зʼєднаних «і» або «або». Під конструктором програма розшифровує зібране звичайними словами, щоб можна було перечитати й переконатися, що вийшло саме те, що задумували.
1
Конструктор умови2
Розшифровка умови3
Зберегти умову- У конструкторі рядок за рядком збирається умова: поле, оператор, значення.
- Світла плашка одразу показує, у що склалась умова, звичайними словами.
- Умова зберігається окремою кнопкою — решта полів картки зберігається сама.
Список полів береться з вашої сітки документів або контрагентів. Це дає доступ до сотень полів, включно з вашими власними, але має зворотний бік: у співробітника, який ще жодного разу не відкривав відповідний список, конструктор буде порожнім. Лікується просто — відкрити список, налаштувати колонки й повернутися до правила.
Оператори залежать від типу поля:
- число — дорівнює, не дорівнює, менше, менше або дорівнює, більше, більше або дорівнює, між;
- дата і текст — усе перелічене плюс порожньо, не порожньо, містить, не містить;
- статус документа, статус і вид оплати, статус і вид доставки, група контрагента, мова, валюта — дорівнює, не дорівнює, з указаних, не з указаних, зі списком готових значень;
- склад і тип документа — дорівнює і порожньо;
- так/ні — тільки дорівнює, зі списком «Так» і «Ні».
Залишки позицій документа умова бачить лише в події «Документ: проводка (підпис)»: там зʼявляється поле «Залишок товару на складі». В інших подіях такого поля немає.
Підстановки дат
У значенні умови замість конкретної дати можна написати підстановку, і програма підмінить її в момент перевірки. Їх три: {current_date}, {current_datetime} і {current_time}. До кожної дописується зсув: знак плюс або мінус, число і одиниця — minute, hour, day, week, month, year.
У самій програмі ці зразки лежать під написом «Підказка: підстановки дати в умовах», кліком по зразку він копіюється. Приклад із підказки: умова «Оплатити до» менше {current_date-3day} означає «прострочено більше трьох днів».
«Початкове значення» — реакція на зміну
У списках значень статусів документа, оплати й доставки, видів оплати й доставки, мови й валюти є окремий пункт «Початкове значення». Він працює тільки в парі з оператором «не дорівнює» і читається так: «поле стало не таким, яким було до збереження». Тобто правило спрацює саме на зміну, а не на кожне збереження картки.
У списках складу й компанії цей пункт теж видно, але скористатися ним там не вийде: оператора «не дорівнює» для цих полів немає — тільки «дорівнює» і «порожньо».
У цього пункту є другий, менш очевидний ефект: коли значення справді змінилося, програма чистить журнал спрацювань для цього запису. Тому правило зі «Початковим значенням» може спрацьовувати по одному й тому самому документу знову й знову — щоразу, коли поле змінюється.
Умова зберігається окремою кнопкою «Зберегти умову» під конструктором. Решта полів картки — назва, примітка, тумблер «Активність», «Період перевірки» — записуються самі, щойно ви пішли з поля, кнопки для них немає. Через це легко зібрати умову, закрити вікно й отримати правило зі старою умовою: назва збереглася, а умова ні.
Поруч стоїть «Очистити умову» — вона прибирає всі рядки з конструктора, але в базі умова лишається старою, поки ви не натиснули «Зберегти умову».
Один раз на запис — і більше ніколи
Це найчастіше джерело питання «правило ввімкнене, а листа немає». Програма веде окремий журнал спрацювань: для кожної пари «команда + запис» вона запамʼятовує, що вже відпрацювала. Другого разу по тому самому документу команда не виконається.
Поведінкою керує поле «Період перевірки» в першій секції картки й сусіднє поле «Одиниця виміру» зі значеннями: секунд, хвилин, годин, днів, тижень, місяців, кварталів, років.
- 0 — значення, з яким правило створюється. Означає «жодного повтору»: одна команда, один запис, один раз за все життя правила.
- Більше нуля — запис у журналі старший за вказаний строк видаляється, і команда може відпрацювати знову. «1 день» читається як «не частіше ніж раз на добу по одному запису».
Третій спосіб отримати повтор — умова з пунктом «Початкове значення»: коли поле справді змінилося, журнал для цього запису чиститься повністю.
Сценарії
- Один лист на кожне нове замовлення — подія «Документ: додавання», умова «Тип документа» дорівнює «Замовлення покупця», «Період перевірки» 0. Повністю: лист-підтвердження.
- Нагадування щодня, поки рахунок не оплачено — подія «Документ: прострочено оплату», «Період перевірки» 1 день. Повністю: нагадування про оплату.
- SMS лише тоді, коли змінили статус — умова «Статус документа» не дорівнює «Початкове значення» і дорівнює потрібному статусу. Повністю: SMS за статусом.
- Прохання про відгук через три дні після відвантаження — подія «Документ: оновлення», умова з підстановкою дати, «Період перевірки» 0: нагадування має піти один раз.
Що робити, коли правило не реагує
| Що ви бачите | Чому так | Що зробити |
|---|---|---|
| Правило ввімкнене, подія сталася, у журналі нічого | Найчастіше — команда вже відпрацювала по цьому запису раніше, а «Період перевірки» дорівнює нулю | Поставити «Період перевірки» більше нуля або додати в умову пункт «Початкове значення» (про повтори) |
| У секції «Умова» немає жодного поля для вибору | Список полів береться з вашої сітки документів чи контрагентів, а ви цей список ще не відкривали | Відкрити відповідний список, налаштувати колонки, повернутися до правила (про умову) |
| Зібрали умову, закрили вікно — умова стара | Умова зберігається окремою кнопкою, решта полів картки — сама | Натиснути «Зберегти умову» під конструктором (про умову) |
| Умова про прострочену оплату стоїть, а правило мовчить | Ця подія приходить тільки від системного розкладу, раз на 32 хвилини, і лише для документів, у яких «Оплатити до» минуло не більше ніж 90 днів тому, а дата оплати не заповнена. За прогін розклад бере до 300 таких документів, починаючи з найновіших | Перевірити, що оплата справді не проставлена і строк минув не більше ніж 90 днів тому (про прострочену оплату) |
| «Умову не збережено: замість поля в ній вираз. Відкрийте умову заново й збережіть ще раз.» | Повідомлення зʼявляється на будь-яку помилку розбору умови: у лівій колонці вираз замість поля зі списку; оператор, якого конструктор не знає; для «між» заповнене одне значення з двох; групи поєднані не через AND/OR; умова пошкоджена. Майже завжди це умова, збережена старішою версією програми | Закрити картку, відкрити знову, видалити дивні рядки, зібрати їх наново полями зі списку, заповнити обидва значення «між» і натиснути «Зберегти умову». Дату порівнювати підстановкою у значенні: «Оплатити до» → менше → {current_date-3day} |
Часті запитання
Чи можна змінити подію в готовому правилі?
Ні. Подія вибирається один раз при створенні, у картці правила її не змінити. Потрібна інша подія — заведіть нове правило.
Чому замовлення, додане вручну, не отримало листа за правилом на додавання?
Подія створення, яку піднімає ручне додавання зі списку документів, не несе номера документа, і правило такий запис пропускає. Лист за «Документ: додавання» йде на замовлення, завантажені з сайту.
Чому правило на «Документ: видалення» нічого не робить?
На момент перевірки документа в базі вже немає. Для контрагента ця подія працює: картка переїжджає в кошик і лишається доступною правилу.
Чи можна зловити зміну складу чи компанії через «Початкове значення»?
Ні. У цих списках пункт видно, але оператора «не дорівнює» для складу й компанії немає — тільки «дорівнює» і «порожньо» (про «Початкове значення»).
Чому немає нагадування про рахунок, прострочений пів року тому?
Системний розклад бере лише документи, у яких «Оплатити до» минуло не більше ніж 90 днів тому. Старіші з відбору випадають.
Суміжні теми
- Якщо потрібна загальна картина, — як працюють автоматичні правила.
- Якщо умову зібрано і треба вибрати, що зробити, — команди правила.
- Якщо правило ввімкнене, а в журналі порожньо чи «Не виконано!», — як перевірити правило.