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

Зміст

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Валідація (перевірка) дозволить контролювати заповнення даних в 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'

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

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