Кейс "Договор закупівлі"

Цей приклад демонструє, як побудувати комплексну систему контролю, де кожен крок — від інформування менеджера до фінального підпису Директора — керується «розумними» алгоритмами.

Матриця відповідальності (Підготовка даних): Замість того, щоб вписувати прізвища в правила, ми створюємо Таблиці та Атрибути. Це дозволяє системі працювати автономно.

Повний перелік бізнес-вимог

Документ: Договір закупівлі (Шаблон: Договір з контрагентом).

1. Ініціація: Обов'язкове погодження автором.

2. Інформування: Автоматичне надання доступу менеджеру контрагента.

3. Безпека (СБ): Погодження співробітником СБ за регіоном, якщо контрагент не валідований.

4. Профільні служби: Юрист (за підрозділом) та Бухгалтер (за організацією).

5. Фінансовий ліміт: Погодження Власником бюджету, якщо сума > 20 000 грн (якщо менше — просто відкриття доступу).

6. Зовнішній підпис: Підписант контрагента з поля «Сторони».

7. Фінальний контроль: Підпис Директора нашої компанії (з блокуванням, якщо контрагент не має статусу «Валідований»).

Технічний чеклист підготовки (Архітектура)

Якщо типу документа Договір закупівлі немає, то створюємо його. Якщо шаблон документа Договір з контрагентом ще не доданий, то створюємо його. Перш ніж створювати правило, необхідно налаштувати «фундамент» — довідники та атрибути.

Створюємо довідники

• Регіони (Київ, Львів, Полтава...).

• Бюджети (Виробництво, Продажі, Центральний офіс...).

Налаштовуємо атрибути (Зв’язки)

Додаємо атрибути

Додаємо атрибут Бюджет для типу документа Договір закупівлі.

Заповнюємо атрибути там, де це потрібно: для контрагентів - Менеджер, Регіон_Контрагенти і Підписант контрагента, для організації - Бухгалтер і Директор і для підрозділів - Юрист. Додаємо і заповнюємо значеннями для посад, де це потрібно - Регіон_СБ, Власник бюджету.

Налаштування логіки

Етап 1: Інформування та доступ

Замість погоджень ми використовуємо дію «Відкрити доступ».

• Система через Формулу 2-го типу знаходить Менеджера, закріпленого за Контрагентом у полі «Сторони».

Етап 2: Динамічне погодження (Юрист та СБ)

• Юрист: Підбирається автоматично за підрозділом ініціатора. Логіка: «Знайди посаду, у якої атрибут "Юрист" збігається з підрозділом автора документа». Ви не вказуєте посаду - система сама знає, хто «веде» цей відділ.

• Служба безпеки: Якщо атрибут Валідований у картці контрагента = Ні, система активує крок СБ (служба безпеки). Виконується пошук Суб'єкта (Посади), у якого атрибут Регіон_СБ збігається з атрибутом Регіон_Контрагента документа. Логіка: Система бере регіон із картки контрагента і через Формулу 2-го типу знаходить співробітника СБ, у якого в профілі вказаний цей самий регіон.

Етап 3: Фінансовий поріг (20 000 грн)

Крок правила містить розгалуження:

• IF Сума > 20 000 -> Дія: Погодження (Власник бюджету). Система звертається до Функції, яка йде в Таблицю “Бюджети”, знаходить потрібний ЦФВ (центр фінансової відповідальності) і повертає “Власника бюджету” в план підписів.

• ELSE -> Дія: Відкриття доступу.

Етап 4: Зовнішній підпис (Сторони)

Система автоматично витягує контакт підписанта з картки контрагента, вказаного в документі. Вам не потрібно щоразу шукати e-mail чи ПІБ — Шрифт робить це за вас.

Етап 5: Контрольний підпис Директора

Це найважливіший механізм безпеки.

• У налаштуваннях дії «Підпис Директора» вказується додаткова умова: статус контрагента має бути «Валідований».

• Якщо статус інший — система заблокує можливість підписання, доки СБ або Менеджер не проведуть валідацію.

Результат для користувача (Smart Experience)

Що бачить ініціатор: Він просто створює документ (за шаблоном “Договір з контрагентом”), вказує суму у полі документа та додає контрагента у полі «Сторони». План підписів на 5-7 осіб вибудовується миттєво.

Що відбувається при зміні даних (Principle of Backward Action): Якщо ініціатор передумав і знизив суму договору з 25 000 до 15 000 грн — “Власник бюджету” миттєво зникає з плану підписів. Система сама «підчищає» маршрут, бо умова правила більше не виконується.

Скріншоти кроків

Крок 1

Крок 2

Крок 3

Крок 4

Крок 5

Формула 2-го типу

Пояснення як слід планувати і розуміти логіку застосування формули 2-го типу. Опис логіки використання формули, які вказані в описаному вище прикладі:

• Ми відкриваємо доступ тим посадам, у яких значення атрибуту Експертиза відповідає типу документа;

  

• Ми додаємо в рядок «Погодження» такі посади, у яких значення атрибуту «Власник бюджету» відповідає значенню атрибуту «Бюджет» у документі;

  

• Ми додамо в рядок «Погодження» такі посади, у яких значення атрибуту Регіон_СБ відповідає значенню атрибуту Регіон_Контрагент, що використовується для контрагента, який є Стороною в документі.

  

У результаті при створенні нового документа відповідного типу, блок Погодження та підписи буде заповнено складом підписів, запланованим правилом автоматизації.