Технічне завдання: Редактор BP-моделей K2 ERP

Редактор BP-моделей K2 ERP — модуль для графічного проєктування бізнес-процесів, маршрутизації документів, workflow-сценаріїв, погоджень, автоматичних дій, інтеграцій, правил переходів і виконавців. Результатом роботи редактора є структурований опис процесу у форматі YAML, з якого можуть генеруватися виконувані workflow, код, конфігурації BPM-рушія, документація та інтеграційні сценарії.

1. Мета розробки

Розробити в K2 ERP графічний редактор BP-моделей, який дозволяє:

• створювати бізнес-процеси у графічному вигляді;
• описувати етапи, задачі, події, переходи, умови та виконавців;
• задавати правила погодження документів;
• описувати автоматичні дії системи;
• налаштовувати інтеграційні кроки;
• зберігати модель процесу у YAML;
• версіонувати бізнес-процеси;
• перевіряти процес на логічні помилки;
• генерувати виконувані workflow-схеми;
• формувати документацію по процесу;
• використовувати BP-модель як єдине джерело правди для виконання бізнес-процесу.

2. Основна концепція

Редактор BP-моделей має працювати за принципом:

Графічний редактор бізнес-процесу
        ↓
YAML BP-модель
        ↓
Генератори / інтерпретатор
        ↓
Workflow engine / BPMN / код / документація

Приклад цільового сценарію:

K2 BP Editor

   ↓

purchase_approval.yml

   ↓

K2 Workflow Engine

   ↓

Виконання процесу погодження закупівлі
purchase_approval.yml

   ↓

BPMN generator

   ↓

purchase_approval.bpmn
purchase_approval.yml

   ↓

Python workflow generator

   ↓

workflow_handlers.py
purchase_approval.yml

   ↓

Markdown documentation generator

   ↓

process_docs.md

3. Основні принципи

Принцип	Опис
Process-first	Спочатку моделюється бізнес-процес, потім він виконується або генерується в код.
YAML як source of truth	YAML-файл є основним джерелом опису процесу.
Graphical-first	Основна робота виконується через графічний редактор.
Двостороння синхронізація	Діаграма оновлює YAML, а YAML може перебудувати діаграму.
Workflow-agnostic	Модель не має бути жорстко привʼязана до одного BPM-рушія.
Виконуваність	BP-модель має бути придатною для запуску в K2 Workflow Engine.
Валідація	Перед публікацією процес перевіряється на помилки.
Версіонування	Кожна зміна процесу має зберігатися як версія.
Розширюваність	Має бути можливість додавати нові типи вузлів, дій і генераторів.

4. Терміни та визначення

Термін	Опис
BP-модель	Структурований опис бізнес-процесу.
Бізнес-процес	Послідовність дій, рішень, подій і автоматичних операцій.
Workflow	Виконувана логіка процесу в системі.
Node / Вузол	Елемент процесу: старт, задача, умова, дія, завершення.
Transition / Перехід	Звʼязок між вузлами процесу.
Task / Задача	Дія, яку виконує користувач або система.
Gateway	Умова або розгалуження процесу.
Event	Подія, яка запускає, зупиняє або змінює процес.
Actor	Виконавець задачі: користувач, роль, група, менеджер, система.
SLA	Обмеження часу на виконання задачі або процесу.
Escalation	Автоматичне підняття задачі на інший рівень при порушенні SLA.
Approval	Погодження документа або дії.
Script action	Автоматична дія, яка виконує код або функцію.
Integration action	Автоматична дія, яка викликає зовнішній API або сервіс.

5. Основні користувачі

Роль	Опис	Основні дії
Бізнес-аналітик	Описує логіку бізнес-процесів.	Створення схем, опис етапів, правил і виконавців.
Архітектор	Контролює структуру процесів і їх інтеграцію з K2 ERP.	Валідація архітектури, звʼязок з ER-моделями та модулями.
Backend-розробник	Реалізує автоматичні дії, інтеграції та генератори.	Підключення handler-ів, scripts, API.
Адміністратор	Налаштовує права, версії, доступи, публікацію.	Управління моделями та доступами.
Керівник	Затверджує бізнес-процеси.	Review, approval, контроль процесів.
Користувач ERP	Виконує задачі в рамках процесу.	Погодження, виконання, коментування задач.

6. Функціональні блоки редактора

Редактор BP-моделей має містити:

• графічне полотно процесу;
• панель інструментів;
• бібліотеку елементів процесу;
• дерево процесу;
• панель властивостей;
• YAML-редактор;
• валідатор процесу;
• менеджер ролей і виконавців;
• менеджер умов;
• менеджер SLA;
• менеджер автоматичних дій;
• менеджер інтеграцій;
• менеджер версій;
• генератор workflow;
• preview виконання процесу;
• симулятор процесу;
• журнал змін;
• експорт та імпорт.

7. Загальний вигляд інтерфейсу

Рекомендована структура екрана:

+--------------------------------------------------------------------------------+
| Верхня панель: Назва BP-моделі | Save | Validate | Simulate | Publish | Export |
+----------------------+-----------------------------------------+---------------+
| Бібліотека елементів | Графічне полотно BP-діаграми            | Властивості   |
|                      |                                         |               |
| - Start Event        |  Start → Task → Gateway → Approval      | Node/Transition|
| - User Task          |             ↓        ↓                  | settings      |
| - System Task        |          Reject     Approve             |               |
| - Gateway            |             ↓        ↓                  |               |
| - End Event          |            End      System Action       |               |
+----------------------+-----------------------------------------+---------------+
| Нижня панель: Errors | Warnings | YAML | Simulation | Generated Code | History  |
+--------------------------------------------------------------------------------+

8. Графічне полотно BP-діаграми

8.1. Основні вимоги

Графічне полотно має дозволяти:

• створювати процеси drag-and-drop;
• розміщувати вузли процесу;
• зʼєднувати вузли переходами;
• налаштовувати умови переходів;
• переміщувати вузли;
• групувати етапи у swimlane-и;
• масштабувати діаграму;
• автоматично розкладати процес;
• фільтрувати видимі вузли;
• підсвічувати шлях виконання;
• показувати помилки прямо на схемі;
• відкривати властивості вузла або переходу.

8.2. Дії користувача на полотні

Дія	Опис
Drag елемента з бібліотеки	Додати новий вузол процесу.
Клік по вузлу	Відкрити властивості вузла.
Подвійний клік по вузлу	Відкрити розширене редагування.
Drag від одного вузла до іншого	Створити перехід.
Клік по переходу	Відкрити умови переходу.
Delete	Видалити вибраний вузол або перехід після підтвердження.
Ctrl + Z	Скасувати останню дію.
Ctrl + Y	Повторити дію.
Ctrl + колесо миші	Масштабувати схему.

9. Типи вузлів процесу

Редактор має підтримувати такі типи вузлів.

Тип вузла	Код	Опис
Start Event	start	Початок процесу.
End Event	end	Завершення процесу.
User Task	user_task	Задача, яку виконує користувач.
Approval Task	approval_task	Задача погодження.
System Task	system_task	Автоматична дія системи.
Script Task	script_task	Виконання скрипта або handler-а.
Integration Task	integration_task	Виклик зовнішнього API.
Notification Task	notification_task	Надсилання повідомлення.
Timer Event	timer	Очікування часу або дедлайну.
Gateway	gateway	Умова або розгалуження.
Parallel Gateway	parallel_gateway	Паралельне виконання гілок.
Join Gateway	join_gateway	Обʼєднання паралельних гілок.
Subprocess	subprocess	Виклик іншого бізнес-процесу.
Error Event	error	Обробка помилки.

10. Властивості BP-моделі

10.1. Загальні поля процесу

Поле	Тип	Обовʼязкове	Опис
name	string	Так	Технічна назва процесу.
code	string	Так	Унікальний код процесу.
label	string	Так	Людинозрозуміла назва.
description	text	Ні	Опис процесу.
module	string	Так	Модуль K2 ERP.
version	string	Так	Версія процесу.
status	enum	Так	draft, review, approved, released, archived.
entity	reference	Ні	ER-сутність або документ, до якого привʼязаний процес.
trigger	object	Так	Умова запуску процесу.
variables	list	Ні	Змінні процесу.
nodes	list	Так	Вузли процесу.
transitions	list	Так	Переходи між вузлами.
permissions	object	Ні	Права доступу.
sla	object	Ні	Загальні SLA процесу.

11. Start Event

11.1. Призначення

Start Event визначає, як запускається процес.

11.2. Типи запуску

Тип запуску	Опис	Приклад
manual	Запуск користувачем вручну.	Користувач натиснув “Запустити погодження”.
document_created	Запуск при створенні документа.	Створено рахунок.
document_status_changed	Запуск при зміні статусу документа.	Замовлення перейшло у статус “На погодженні”.
scheduled	Запуск за розкладом.	Щодня о 09:00.
webhook	Запуск зовнішнім HTTP-запитом.	Подія з сайту або CRM.
event	Запуск внутрішньою подією K2 ERP.	Оплата отримана.

11.3. Властивості Start Event

Поле	Тип	Опис
id	string	Унікальний ID вузла.
type	string	start.
trigger_type	enum	manual, document_created, document_status_changed, scheduled, webhook, event.
entity	string	Сутність або документ, який запускає процес.
condition	expression	Додаткова умова запуску.
label	string	Назва вузла на діаграмі.

12. User Task

12.1. Призначення

User Task — задача, яку виконує користувач ERP.

Приклади:

• перевірити документ;
• заповнити додаткові поля;
• прикріпити файл;
• підтвердити виконання;
• залишити коментар;
• обрати наступну дію.

12.2. Властивості User Task

Поле	Тип	Обовʼязкове	Опис
id	string	Так	Унікальний ID вузла.
type	string	Так	user_task.
name	string	Так	Технічна назва задачі.
label	string	Так	Назва для користувача.
description	text	Ні	Інструкція для виконавця.
assignee_type	enum	Так	user, role, group, manager, expression.
assignee	string	Так	Хто виконує задачу.
form	reference	Ні	Форма, яку потрібно показати.
required_fields	list	Ні	Поля, які потрібно заповнити.
actions	list	Так	Доступні дії користувача.
sla	object	Ні	SLA задачі.
notifications	list	Ні	Повідомлення по задачі.

12.3. Дії користувача в User Task

Приклади дій:

Дія	Опис
approve	Погодити.
reject	Відхилити.
return	Повернути на доопрацювання.
complete	Завершити задачу.
cancel	Скасувати процес.
delegate	Делегувати іншому користувачу.
request_info	Запросити додаткову інформацію.

13. Approval Task

13.1. Призначення

Approval Task використовується для погодження документів, заявок, платежів, договорів або інших обʼєктів K2 ERP.

13.2. Типи погодження

Тип	Опис
single	Потрібне погодження одного виконавця.
sequential	Послідовне погодження кількома рівнями.
parallel_all	Паралельне погодження, всі мають погодити.
parallel_any	Паралельне погодження, достатньо одного погодження.
majority	Потрібна більшість голосів.

13.3. Властивості Approval Task

Поле	Тип	Опис
approval_type	enum	single, sequential, parallel_all, parallel_any, majority.
approvers	list	Список погоджувачів.
reject_policy	enum	stop_process, return_to_author, continue.
allow_delegate	boolean	Чи дозволено делегування.
require_comment_on_reject	boolean	Чи обовʼязковий коментар при відхиленні.
require_signature	boolean	Чи потрібний електронний підпис.

14. System Task

14.1. Призначення

System Task — автоматична дія, яку виконує K2 ERP без участі користувача.

Приклади:

• змінити статус документа;
• створити запис;
• оновити поле;
• сформувати друковану форму;
• створити задачу;
• провести документ;
• надіслати повідомлення;
• запустити інший процес.

14.2. Типи системних дій

Тип дії	Опис
update_entity	Оновити поля сутності.
create_entity	Створити новий запис.
change_status	Змінити статус документа.
call_service	Викликати внутрішній сервіс K2 ERP.
generate_document	Сформувати документ або друковану форму.
send_notification	Надіслати повідомлення.
start_process	Запустити інший BP-процес.

15. Script Task

15.1. Призначення

Script Task дозволяє виконати код або handler, зареєстрований у K2 ERP.

15.2. Властивості Script Task

Поле	Тип	Опис
handler	string	Назва handler-а.
language	enum	python, javascript, sql, internal.
input	object	Вхідні параметри.
output	object	Очікуваний результат.
timeout	integer	Максимальний час виконання.
retry_policy	object	Правила повтору.

Статус	Правило
Рекомендовано	Використовувати зареєстровані handler-и, а не довільний код у YAML.
Заборонено	Виконувати небезпечний довільний код без sandbox і прав доступу.

16. Integration Task

16.1. Призначення

Integration Task викликає зовнішній API або інтеграційний сервіс.

Приклади:

• відправити рахунок у зовнішню систему;
• перевірити статус оплати;
• створити заявку в CRM;
• викликати сервіс доставки;
• відправити дані в податкову систему;
• викликати webhook.

16.2. Властивості Integration Task

Поле	Тип	Опис
method	enum	GET, POST, PUT, PATCH, DELETE.
url	string	Endpoint або посилання на інтеграційний конектор.
headers	object	HTTP-заголовки.
body	object	Тіло запиту.
auth	reference	Посилання на налаштування авторизації.
timeout	integer	Timeout запиту.
retry_policy	object	Правила повтору.
success_condition	expression	Умова успішного виконання.
error_transition	string	Перехід у разі помилки.

17. Gateway

17.1. Призначення

Gateway використовується для розгалуження процесу за умовами.

17.2. Типи gateway

Тип	Опис
exclusive	Виконується тільки одна гілка.
inclusive	Може виконатися одна або кілька гілок.
parallel	Виконуються всі гілки паралельно.
event_based	Перехід залежить від події.

17.3. Приклад умов

document.amount > 100000
document.currency == "UAH"
user.role == "finance_manager"
approval.result == "approved"

18. Transition / Перехід

18.1. Призначення

Transition визначає, як процес переходить від одного вузла до іншого.

18.2. Властивості transition

Поле	Тип	Обовʼязкове	Опис
id	string	Так	ID переходу.
from	string	Так	Початковий вузол.
to	string	Так	Наступний вузол.
label	string	Ні	Назва переходу.
condition	expression	Ні	Умова переходу.
action	string	Ні	Дія користувача, яка запускає перехід.
priority	integer	Ні	Пріоритет, якщо кілька умов істинні.

19. Змінні процесу

BP-модель має підтримувати змінні процесу.

19.1. Типи змінних

Тип	Опис
string	Рядок.
integer	Ціле число.
decimal	Десяткове число.
boolean	Логічне значення.
date	Дата.
datetime	Дата та час.
reference	Посилання на сутність K2 ERP.
object	JSON-обʼєкт.
list	Список.

19.2. Джерела змінних

Джерело	Опис
document	Поля документа, який запустив процес.
user	Дані користувача.
task	Дані поточної задачі.
system	Системні змінні.
integration	Результати зовнішнього API.
manual	Значення, введені користувачем.

20. Умови та expression language

Редактор має мати простий механізм для задання умов.

20.1. Вимоги

Expression language має дозволяти:

• порівнювати значення;
• перевіряти статуси;
• перевіряти ролі;
• працювати з сумами;
• перевіряти наявність значень;
• використовувати AND / OR / NOT;
• звертатися до змінних процесу.

20.2. Приклади умов

document.amount > 100000
document.status == "draft"
document.currency == "UAH" and document.amount <= 50000
user.has_role("finance_manager")
approval.result == "rejected"

Статус	Правило
Рекомендовано	Використовувати обмежену безпечну expression language.
Заборонено	Дозволяти виконання довільного Python/SQL/JS у звичайних умовах.

21. SLA та ескалації

21.1. SLA задачі

Для кожної задачі можна задати:

Поле	Опис
due_in	Час на виконання задачі.
calendar	Робочий календар.
reminder_before	Коли нагадати до дедлайну.
escalation_after	Коли ескалювати після прострочки.
escalation_to	Кому ескалювати.

21.2. Приклад SLA

sla:
  due_in: 2d
  calendar: business_days
  reminder_before: 4h
  escalation_after: 1d
  escalation_to:
    type: role
    value: department_head

22. Повідомлення

Редактор має дозволяти налаштовувати повідомлення.

22.1. Канали повідомлень

Канал	Опис
in_app	Повідомлення всередині K2 ERP.
email	Email.
telegram	Telegram-бот.
sms	SMS.
webhook	Webhook у зовнішню систему.

22.2. Події для повідомлень

• створення задачі;
• наближення SLA;
• прострочка задачі;
• погодження;
• відхилення;
• завершення процесу;
• помилка інтеграції.

23. YAML-формат BP-моделі

23.1. Загальна структура YAML

version: 1

process:
  code: purchase_approval
  name: PurchaseApproval
  label: Purchase approval
  module: purchases
  status: draft
  entity: PurchaseOrder

settings:
  allow_manual_start: true
  allow_cancel: true
  audit: true

variables: []

nodes: []

transitions: []

23.2. Приклад повної BP-моделі

version: 1

process:
  code: purchase_approval
  name: PurchaseApproval
  label: Погодження закупівлі
  description: Процес погодження заявки на закупівлю
  module: purchases
  entity: PurchaseOrder
  status: draft

settings:
  allow_manual_start: true
  allow_cancel: true
  audit: true
  default_task_priority: normal

variables:
  - name: amount
    type: decimal
    source: document.amount

  - name: currency
    type: string
    source: document.currency

  - name: requester
    type: reference
    source: document.created_by

nodes:
  - id: start
    type: start
    label: Старт
    trigger_type: document_status_changed
    entity: PurchaseOrder
    condition: document.status == "approval_required"

  - id: manager_approval
    type: approval_task
    name: ManagerApproval
    label: Погодження керівником
    assignee_type: expression
    assignee: document.created_by.manager
    approval_type: single
    require_comment_on_reject: true
    actions:
      - approve
      - reject
      - return
    sla:
      due_in: 2d
      reminder_before: 4h
      escalation_after: 1d
      escalation_to:
        type: role
        value: department_head

  - id: amount_gateway
    type: gateway
    label: Перевірка суми
    gateway_type: exclusive

  - id: finance_approval
    type: approval_task
    name: FinanceApproval
    label: Погодження фінансистом
    assignee_type: role
    assignee: finance_manager
    approval_type: single
    actions:
      - approve
      - reject
    sla:
      due_in: 1d

  - id: change_status_approved
    type: system_task
    name: ChangeStatusApproved
    label: Змінити статус на погоджено
    action:
      type: change_status
      entity: PurchaseOrder
      status: approved

  - id: change_status_rejected
    type: system_task
    name: ChangeStatusRejected
    label: Змінити статус на відхилено
    action:
      type: change_status
      entity: PurchaseOrder
      status: rejected

  - id: end_approved
    type: end
    label: Завершено: погоджено
    result: approved

  - id: end_rejected
    type: end
    label: Завершено: відхилено
    result: rejected

transitions:
  - id: t_start_manager
    from: start
    to: manager_approval

  - id: t_manager_approved
    from: manager_approval
    to: amount_gateway
    action: approve

  - id: t_manager_rejected
    from: manager_approval
    to: change_status_rejected
    action: reject

  - id: t_amount_low
    from: amount_gateway
    to: change_status_approved
    condition: document.amount <= 100000

  - id: t_amount_high
    from: amount_gateway
    to: finance_approval
    condition: document.amount > 100000

  - id: t_finance_approved
    from: finance_approval
    to: change_status_approved
    action: approve

  - id: t_finance_rejected
    from: finance_approval
    to: change_status_rejected
    action: reject

  - id: t_approved_end
    from: change_status_approved
    to: end_approved

  - id: t_rejected_end
    from: change_status_rejected
    to: end_rejected

24. Двостороння синхронізація Diagram ↔ YAML

Редактор має підтримувати два режими:

Режим	Опис
Diagram-first	Користувач редагує графічну діаграму, YAML оновлюється автоматично.
YAML-first	Користувач редагує YAML, діаграма перебудовується після валідації.

24.1. Правила синхронізації

1. Кожна зміна на діаграмі оновлює внутрішню BP-модель.
2. Внутрішня модель серіалізується у YAML.
3. Якщо користувач редагує YAML, виконується парсинг.
4. Якщо YAML валідний — оновлюється діаграма.
5. Якщо YAML невалідний — показується помилка з рядком і полем.

25. Валідація BP-моделі

25.1. Обовʼязкові перевірки

Перевірка	Рівень	Опис
Один start node	Error	Процес має мати рівно один стартовий вузол.
Мінімум один end node	Error	Процес має мати хоча б один фінальний вузол.
Унікальність node.id	Error	Не може бути двох вузлів з однаковим ID.
Валідність transitions	Error	Усі переходи мають посилатися на існуючі вузли.
Досяжність вузлів	Error	Не має бути вузлів, до яких неможливо дійти зі старту.
Вихід із gateway	Error	Gateway має мати мінімум два вихідні переходи.
Умови gateway	Warning	Для exclusive gateway бажано мати default-гілку.
User task без виконавця	Error	Користувацька задача має мати assignee.
Approval task без дій	Error	Approval task має мати approve/reject або інші дії.
SLA без escalation	Warning	Якщо є SLA, бажано налаштувати escalation.
Нескінченний цикл	Warning/Error	Цикли мають бути явно дозволені.

25.2. Рівні повідомлень

Рівень	Опис	Блокує публікацію
Error	Критична помилка процесу.	Так.
Warning	Потенційна проблема.	Ні.
Info	Інформаційне повідомлення.	Ні.

26. Симулятор процесу

Редактор має мати режим симуляції.

26.1. Мета симулятора

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

26.2. Можливості симулятора

• задати тестові значення змінних;
• пройти процес по кроках;
• побачити активні задачі;
• перевірити умови gateway;
• перевірити маршрути погодження;
• перевірити SLA;
• перевірити помилки;
• побачити фінальний результат процесу.

26.3. Приклад симуляції

document.amount = 150000
document.currency = UAH
manager action = approve
finance action = approve

Очікуваний шлях:
start → manager_approval → amount_gateway → finance_approval → change_status_approved → end_approved

27. Генерація виконуваного workflow

27.1. Основна ідея

YAML-модель має використовуватися для генерації або інтерпретації workflow.

bp_model.yml
    ↓
K2 Workflow Engine
    ↓
Process runtime

27.2. Генератори

Генератор	Пріоритет	Результат
K2 Workflow Engine	Високий	Виконувана схема процесу.
BPMN 2.0	Високий	BPMN XML.
Markdown documentation	Високий	Документація процесу.
Python handlers	Середній	Каркас handler-ів для script/system task.
TypeScript types	Середній	Типи змінних і задач.
Mermaid diagram	Середній	Mermaid-схема процесу.

27.3. Налаштування генераторів

generators:
  - name: k2_workflow
    enabled: true
    output: ./generated/workflows
    options:
      generate_runtime_schema: true
      validate_handlers: true

  - name: bpmn
    enabled: true
    output: ./generated/bpmn
    options:
      include_documentation: true

  - name: python_handlers
    enabled: true
    output: ./generated/python
    options:
      create_stub_handlers: true

28. Виконання процесу в K2 ERP

28.1. Runtime-сутності

Для виконання BP-моделей потрібно створити runtime-сутності.

bp_models
bp_model_versions
bp_process_instances
bp_task_instances
bp_process_variables
bp_process_events
bp_audit_log

28.2. bp_process_instances

Поле	Тип	Опис
id	uuid	ID екземпляра процесу.
model_id	uuid	BP-модель.
model_version_id	uuid	Версія моделі.
status	enum	running, completed, cancelled, failed, suspended.
entity	string	Сутність, з якою повʼязаний процес.
entity_id	uuid/string	ID документа або запису.
current_nodes	list	Активні вузли процесу.
started_by	reference	Хто запустив процес.
started_at	datetime	Дата запуску.
completed_at	datetime	Дата завершення.

28.3. bp_task_instances

Поле	Тип	Опис
id	uuid	ID задачі.
process_instance_id	uuid	Екземпляр процесу.
node_id	string	ID вузла з BP-моделі.
label	string	Назва задачі.
assignee	reference	Виконавець.
status	enum	created, assigned, in_progress, completed, rejected, cancelled, expired.
due_at	datetime	Дедлайн задачі.
completed_by	reference	Хто завершив.
completed_at	datetime	Коли завершив.
action	string	Яку дію обрав користувач.
comment	text	Коментар користувача.

29. Версіонування BP-моделей

29.1. Статуси версій

Статус	Опис
draft	Чернетка.
review	Очікує перегляду.
approved	Затверджено.
released	Доступно для запуску нових процесів.
archived	Архівна версія.

29.2. Правила версіонування

Правило	Опис
Released-версія незмінна	Опубліковану версію не можна змінювати напряму.
Нова зміна = нова draft-версія	Для редагування released-процесу створюється нова версія.
Старі екземпляри	Вже запущені процеси продовжують виконуватися на старій версії.
Нові екземпляри	Нові процеси запускаються на актуальній released-версії.

30. Права доступу

Дія	Аналітик	Архітектор	Розробник	Адміністратор	Керівник	Перегляд
Перегляд BP-моделі	Так	Так	Так	Так	Так	Так
Створення BP-моделі	Так	Так	Ні	Так	Ні	Ні
Редагування вузлів	Так	Так	Ні	Так	Ні	Ні
Редагування YAML	Частково	Так	Так	Так	Ні	Ні
Редагування handler-ів	Ні	Так	Так	Так	Ні	Ні
Валідація	Так	Так	Так	Так	Так	Так
Симуляція	Так	Так	Так	Так	Так	Ні
Публікація	Ні	Так	Ні	Так	Так	Ні
Видалення	Ні	Так	Ні	Так	Ні	Ні

31. Audit log

31.1. Що логувати

• створення BP-моделі;
• зміну назви процесу;
• додавання вузла;
• видалення вузла;
• зміну властивостей вузла;
• створення переходу;
• зміну умови переходу;
• видалення переходу;
• зміну SLA;
• зміну виконавців;
• зміну YAML;
• запуск симуляції;
• генерацію workflow;
• зміну статусу версії;
• публікацію процесу.

31.2. Поля audit log

Поле	Опис
user	Користувач, який зробив зміну.
action	Тип дії.
object_type	Process, Node, Transition, Variable, Version.
object_id	ID обʼєкта.
old_value	Старе значення.
new_value	Нове значення.
created_at	Дата зміни.
comment	Коментар користувача.

32. Імпорт та експорт

32.1. Імпорт

Редактор має підтримувати імпорт із:

• YAML;
• JSON;
• BPMN 2.0;
• Mermaid flowchart;
• PlantUML activity diagram.

Для MVP достатньо:

• YAML;
• BPMN 2.0 у базовому режимі.

32.2. Експорт

Редактор має підтримувати експорт у:

• YAML;
• JSON;
• BPMN 2.0;
• PNG;
• SVG;
• PDF;
• Markdown;
• Mermaid;
• PlantUML.

33. API редактора BP-моделей

Метод	Endpoint	Опис
GET	/api/bp-models	Список BP-моделей.
POST	/api/bp-models	Створити BP-модель.
GET	/api/bp-models/{id}	Отримати BP-модель.
PUT	/api/bp-models/{id}	Оновити BP-модель.
POST	/api/bp-models/{id}/validate	Провалідувати модель.
POST	/api/bp-models/{id}/simulate	Запустити симуляцію.
POST	/api/bp-models/{id}/generate	Запустити генерацію.
POST	/api/bp-models/{id}/publish	Опублікувати модель.
GET	/api/bp-models/{id}/versions	Отримати версії.
POST	/api/bp-models/import	Імпорт BP-моделі.

34. Нефункціональні вимоги

34.1. Продуктивність

Редактор має підтримувати:

• до 300 вузлів в одному процесі;
• до 1 000 переходів;
• відкриття процесу до 100 вузлів — до 3 секунд;
• відкриття процесу до 300 вузлів — до 10 секунд;
• валідація процесу до 300 вузлів — до 5 секунд;
• генерація YAML — до 3 секунд;
• симуляція типового процесу — до 5 секунд.

34.2. Надійність

Система має:

• не втрачати незбережені зміни;
• підтримувати autosave draft;
• не дозволяти публікацію невалідного процесу;
• не змінювати released-версії напряму;
• зберігати історію змін;
• підтримувати rollback до попередньої версії.

34.3. Безпека

Потрібно:

• перевіряти права доступу;
• заборонити виконання довільного небезпечного коду з YAML;
• обмежити script task тільки зареєстрованими handler-ами;
• логувати публікацію та запуск процесів;
• не показувати користувачу задачі, до яких він не має доступу;
• перевіряти, що integration task не відкриває небезпечні внутрішні ресурси.

35. MVP

35.1. Що включити в MVP

1. Створення BP-моделі.
2. Графічне полотно.
3. Start Event.
4. End Event.
5. User Task.
6. Approval Task.
7. System Task.
8. Exclusive Gateway.
9. Transitions з умовами.
10. YAML export/import.
11. Валідація процесу.
12. Версіонування draft/released.
13. Базова симуляція.
14. Генерація документації.
15. Генерація runtime-схеми для K2 Workflow Engine.

35.2. Що можна відкласти

1. Live collaboration.
2. BPMN import у повному обсязі.
3. Parallel gateway.
4. Complex event gateway.
5. Mermaid/PlantUML import.
6. Advanced SLA calendar.
7. AI-рекомендації по оптимізації процесу.
8. Повний visual debugger runtime-процесу.
9. Складне merge-версій.

36. Критерії приймання

36.1. Створення процесу

1. Користувач може створити нову BP-модель.
2. Користувач може задати назву, код, модуль і опис.
3. Модель зберігається в K2 ERP.
4. Для моделі створюється draft-версія.

36.2. Робота з вузлами

1. Користувач може додати Start Event.
2. Користувач може додати End Event.
3. Користувач може додати User Task.
4. Користувач може додати Approval Task.
5. Користувач може додати System Task.
6. Користувач може редагувати властивості вузла.
7. Користувач може видалити вузол після підтвердження.

36.3. Робота з переходами

1. Користувач може створити перехід між вузлами.
2. Користувач може задати умову переходу.
3. Користувач може задати дію користувача для переходу.
4. Перехід відображається на діаграмі.
5. Перехід зберігається в YAML.

36.4. YAML

1. Діаграма експортується у валідний YAML.
2. YAML можна імпортувати назад.
3. Після імпорту відновлюються вузли, переходи, умови та властивості.
4. Помилки YAML показуються користувачу.

36.5. Валідація

1. Система знаходить процес без стартового вузла.
2. Система знаходить процес без кінцевого вузла.
3. Система знаходить переходи на неіснуючі вузли.
4. Система знаходить недосяжні вузли.
5. Система не дозволяє опублікувати процес з Error.

36.6. Симуляція

1. Користувач може задати тестові змінні.
2. Система показує шлях виконання процесу.
3. Система показує активні задачі.
4. Система показує результат gateway.
5. Система показує фінальний end node.

36.7. Публікація

1. Draft-версію можна перевести в review.
2. Review-версію можна затвердити.
3. Approved-версію можна опублікувати.
4. Released-версія доступна для запуску.
5. Released-версію не можна змінювати напряму.

37. Приклад сценарію роботи користувача

1. Аналітик створює BP-модель “Погодження закупівлі”.
2. Додає Start Event при зміні статусу PurchaseOrder.
3. Додає Approval Task для керівника.
4. Додає Gateway для перевірки суми.
5. Якщо сума до 100 000 грн — документ погоджується автоматично.
6. Якщо сума понад 100 000 грн — додається погодження фінансиста.
7. Додає System Task для зміни статусу документа.
8. Додає End Event для погодження та відхилення.
9. Запускає валідацію.
10. Запускає симуляцію з різними сумами.
11. Зберігає draft.
12. Передає на review.
13. Архітектор затверджує процес.
14. Адміністратор публікує released-версію.
15. Нові документи PurchaseOrder запускають процес автоматично.

38. Ризики

Ризик	Наслідок	Як зменшити
Процес не має кінцевого вузла	Екземпляри процесу зависають.	Валідація має блокувати публікацію.
Неправильно задані умови gateway	Процес іде не тією гілкою.	Симулятор і default-гілка.
Паралельні задачі створюють конфлікт	Документ може отримати некоректний статус.	Чіткі правила join і блокування документа.
Script task виконує небезпечний код	Ризик безпеки.	Тільки зареєстровані handler-и та sandbox.
Зміна released-процесу	Старі процеси можуть зламатися.	Released-версії незмінні, зміни тільки через нову версію.
Інтеграційний крок не відповідає	Процес зупиняється.	Timeout, retry policy, error transition.

39. Рекомендований план реалізації

39.1. Етап 1. Аналітика

1. Узгодити YAML-схему BP-моделі.
2. Узгодити типи вузлів.
3. Узгодити expression language.
4. Узгодити runtime-модель.
5. Узгодити правила публікації.

39.2. Етап 2. Базовий редактор

1. Створити сторінку BP-редактора.
2. Реалізувати графічне полотно.
3. Реалізувати бібліотеку вузлів.
4. Реалізувати додавання вузлів.
5. Реалізувати панель властивостей.

39.3. Етап 3. Переходи та умови

1. Реалізувати transitions.
2. Реалізувати умови переходів.
3. Реалізувати actions для user/approval task.
4. Реалізувати gateway.

39.4. Етап 4. YAML

1. Реалізувати YAML export.
2. Реалізувати YAML import.
3. Реалізувати YAML preview.
4. Реалізувати двосторонню синхронізацію.

39.5. Етап 5. Валідація та симуляція

1. Реалізувати валідатор.
2. Реалізувати підсвічування помилок.
3. Реалізувати симулятор.
4. Реалізувати test variables.

39.6. Етап 6. Runtime та публікація

1. Створити runtime-сутності.
2. Реалізувати запуск процесу.
3. Реалізувати створення задач.
4. Реалізувати виконання задач.
5. Реалізувати публікацію released-версій.

39.7. Етап 7. Генерація та документація

1. Генерація K2 Workflow schema.
2. Генерація Markdown-документації.
3. Генерація BPMN.
4. Генерація Python handler stubs.

40. Висновок

Редактор BP-моделей K2 ERP має стати центральним інструментом для моделювання та виконання бізнес-процесів у системі.

Ключові вимоги:

• графічне редагування бізнес-процесів;
• підтримка start/end/user/approval/system/gateway вузлів;
• опис переходів, умов, виконавців, SLA та повідомлень;
• збереження BP-моделі у YAML;
• двостороння синхронізація Diagram ↔ YAML;
• валідація перед публікацією;
• симуляція процесу;
• генерація runtime workflow;
• версіонування та audit log;
• підтримка виконання процесів у K2 Workflow Engine.

Для MVP достатньо реалізувати базовий графічний редактор, YAML import/export, User Task, Approval Task, System Task, Exclusive Gateway, валідацію, симуляцію, версіонування та публікацію процесу.