Загальна інформація

Зміст

Загальна інформація

Приклад #1. Контроль заповнення поля на етапі

Приклад #2. Контроль заповнення поля при архівуванні ліда/клієнта

Приклад #3. Контроль наявності відповідального при зміні етапу

Приклад #4. Контроль заповнення поля при результаті (Виграно/Програно)

Приклад #5. Контроль наявності завдань в угодах при переході на етап

Приклад #6. Контроль наявності дзвінків при переході на етап

Приклад #7. Контроль по користувачу

Приклад #8. Контроль наявності ТТН

Приклад #9. Контроль наявності документів

Приклад #10. Контроль доданих товарів в угоді

Приклад #11. Контроль зв'язки товару зі складом

Приклад #12. Контроль оплати по угоді в потрібній воронці продажів

Приклад #13. Контроль наявності тегів при зміні статусу контрагента

Приклад #14. Контроль наявності фіскального чека

Приклад #15. Заборонити редагування дати завершення завдання конкретним користувачам

Додаткова інформація

Загальна інформація

Валідація (перевірка) дозволить контролювати заповнення даних в KeepinCRM, або налаштувати поетапне заповнення полів на різних етапах угоди. Валідація розміщена в розділі: Налаштування => Управління => Валідація.

Важливо!

• Тут вказано тільки декілька прикладів, інші умови створюються по такій же логіці
• Будь-яка некоректна умова може привести до неможливості створення угоди/ліда/клієнта
• В умові можна використовувати майже всі системні змінні та користувацькі, а також умови: AND / OR
• Якщо потрібно контролювати заповненість двох полів - створюються 2 окремі валідації

Структурно валідація складається:

1. Таблиця з даними
2. Умова виконання
3. Текст помилки, яку потрібно вивести, якщо валідація не пройшла

Приклад #1. Контроль заповнення поля на етапі

Якщо потрібно перевірити чи заповнено поле на етапі воронки продажів, то в умові вказати змінну цього поля та назву етапу, на який переносять. Таблиця з даними: Угоди. Приклад:

stage.name == 'Узгодження' and (custom_fields.adriesa_1448991 == '' or custom_fields.adriesa_1448991 == NULL)

Важливо:

• Всі користувацькі поля починаються з custom_fields.
• Змінну користувацького поля можна знайти в налаштуваннях полів (в дужках)
  
• Текст помилки відображається угорі справа
  
  

Приклад #2. Контроль заповнення поля при архівуванні ліда/клієнта

Якщо потрібно перевірити чи заповнено поле при архівуванні ліда/клієнта, то в умові вказати змінну цього поля та системну змінну. Таблиця з даними: Контрагенти. Приклад:

archived and (custom_fields.misto_558 == '' or custom_fields.misto_558 == NULL)

Приклад #3. Контроль наявності відповідального при зміні етапу

Якщо потрібно перевірити пустого відповідального в угоді, то в умові вказати змінну та назву етапу, на який переносять. Таблиця з даними: Угоди. Приклад:

stage.name == 'Відправлено' and (main_responsible_id == '' or main_responsible_id == NULL)

Аналогічно можна налаштувати перевірку в контрагентах, прив'язавшись до іншого поля, наприклад - статус.

Приклад #4. Контроль заповнення поля при результаті (Виграно/Програно)

Якщо потрібно заборонити ставити результат угоди, при незаповненому полі, то потрібно вказати системну змінну та змінну поля, яке повинно бути заповнено. Приклад:

result == 'failed' and (custom_fields.adriesa_1448991 == '' or custom_fields.adriesa_1448991 == NULL)

В залежності від результату:

• failed - Програно
• successful - Виграно

Приклад #5. Контроль наявності завдань в угодах при переході на етап

Якщо потрібно заборонити перехід на етап, якщо немає активних завдань в угоді, то потрібно вказати етап та системні змінні. Приклад:

stage.name == 'Дзвінок' and working_tasks_count==0

Також можна використовувати змінну для контролю всіх завдань, в тому числі завершених: tasks_count

Приклад #6. Контроль наявності дзвінків при переході на етап

Якщо потрібно заборонити перехід на етап/завершити угоду, якщо немає дзвінків в картці клієнта (вхідних/вихідних) з потрібною тривалістю (в цьому прикладі менше 50 секунд), то потрібно вказати етап/результат та системні змінні. Приклад:

stage.name == 'Дзвінок' and (any(client.voip_calls, call, call.billsec <=50) or count(client.voip_calls) == 0)

Приклад #7. Контроль по користувачу

Якщо потрібно дозволити виконувати якусь дію тільки певним користувачам, наприклад користувачу 1 та користувачу 2 дозволити змінювати етап, а всім іншим заборонити, то використовується змінна current_user.name

Приклад зміни етапу:

stage.name == 'Дзвінок' and (current_user.name != 'Користувач 1' and current_user.name != 'Користувач 2')

Приклад завершення угоди:

finished == true and (current_user.name != 'Користувач 1' and current_user.name != 'Користувач 2')

Приклад #8. Контроль наявності ТТН

Якщо потрібно заборонити перехід на етап/завершити угоду/інше, якщо немає ТТН в угоді, то потрібно вказати етап/результат/або інші параметри та системну змінну. Приклад:

stage.name == 'Відправлено' and deliveries_count <= 0

Підтримується: Нова Пошта, УкрПошта та системна доставка

Приклад #9. Контроль наявності документів

Якщо потрібно заборонити перехід на етап/завершити угоду/інше, якщо немає сформованих документів в угоді (в блоці Документи), то потрібно вказати етап/результат/або інші параметри та системну змінну. Приклад:

stage.name == 'Відправлено рахунок' and documents_count <= 0

Враховується будь-який сформований документ, окрім фіскальних чеків

Додатково

Якщо потрібно контролювати генерацію певного документа (по назві), то в умові вказати чітку назву документа. Приклад:

stage.name == 'Відправлено рахунок' and (any(documents, document, document.template.name == 'Рахунок') == false)

Приклад #10. Контроль доданих товарів в угоді

Якщо потрібно заборонити перехід на етап/завершити угоду/інше, якщо не додано жодного товару, то потрібно вказати етап/результат/або інші параметри та системну змінну. Приклад:

stage.name == 'Відправлено' and jobs_count <= 0

Приклад #11. Контроль зв'язки товару зі складом

Якщо потрібно заборонити закриття угоди/перехід на етап та інше, якщо хоч один товар не пов'язаний зі складом (не пов'язаний товар в угоді немає іконки переходу на внутрішню сторінку складу), то потрібно вказати етап/результат/або інші параметри та системну змінну. Приклад:

any(jobs, job, job.product_id == null) and result == 'successful'

Приклад #12. Контроль оплати по угоді в потрібній воронці продажів

Якщо потрібно заборонити закриття угоди/перехід на етап та інше в конкретній воронці продажів, якщо вона несплачена, то потрібно вказати етап/результат/або інші параметри та системну змінну credit. Приклад:

credit != 0.0 and result == 'successful' and funnel.title == 'ГУРТ'

Приклад #13. Контроль наявності тегів при зміні статусу контрагента

Якщо потрібно заборонити зміну статусу контрагента або будь-яких інших полів, якщо не додано жодного тегу в контрагенті, то потрібно вказати системні змінні tags та інші потрібні параметри. Приклад:

status_id == 13 and (tags[0] == NULL or tags[0] == '')

Приклад #14. Контроль наявності фіскального чека

Якщо потрібно заборонити зміни в угоді, якщо не створено фіскального чека від Checkbox, то використовується змінна fiscalized. Приклад:

result == 'successful' and fiscalized == false

Приклад #15. Заборонити редагування дати завершення завдання конкретним користувачам

Якщо потрібно заборонити змінювати дату завершення завдання, то вказується потрібний користувач та потрібне поле, яке дорівнює саме собі. Аналогічно можна налаштовувати інші поля для завдань, угод, контрагентів, але рекомендуємо використовувати меншу к-сть умов, оскільки валідація контролює всі вказані умови і можуть виникнути додаткові блокування дій, наприклад якщо вказати блокування поля на певному етапі, тоді етап також буде заборонено змінювати.

Якщо потрібно додати, щоб була заборона на зміну тільки від конкретного користувача, який створив завдання, то потрібно додати creator_name або creator_id.

current_user.name == 'Ірина' and deadline_at == deadline_at

Додаткова інформація

• Якщо валідація не запустилась, звернути увагу на таке:
  • Чи увімкнена валідація (при створенні вимкнено)
  • Яка таблиця використовується, якщо використовуються змінні з угоди, а вибрана таблиця - Контрагенти то валідація не спрацює
  • Коректність написання назви змінних
• При імпорті замовлень/клієнтів рекомендуємо вимкнути валідації
• В кожної валідації є свій журнал спрацювань (стрілочка у вікні редагування)
• Валідація запускається тільки при нових діях
• Приклад деяких змінних вказано тут
• Валідації доступні на розширеному тарифі
• Якщо виникнуть складнощі при самостійному налаштуванні валідацій, зверніться до служби технічної підтримки
• Допомога, консультація в налаштуванні валідацій виконується тільки через тікети або по email [email protected]