Атестаційні завдання K2 ERP/Система візування та погодження документів

Атестаційне завдання K2 ERP — Система візування та погодження документів — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля електронного документообігу, погодження, візування, підпису, контролю маршрутів, версій, коментарів, строків, аудиту й формування фінальних PDF-документів.

Модуль має забезпечувати повний цикл роботи з документом: створення → завантаження файлу → маршрут погодження → візування → коментарі → доопрацювання → повторне погодження → підпис → фінальний документ → журнал аудиту → архів.

Коротко. Потрібно реалізувати модуль візування документів: типи документів, шаблони маршрутів, учасники погодження, ролі, етапи, статуси, коментарі, версії файлів, підпис паролем або ЕЦП, контроль строків, делегування, PDF-лог, архів, права доступу й AJAX-інтерактив.

Назва завдання

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

Мета завдання

Мета завдання — створити в K2 ERP модуль електронного погодження документів для підприємства.

Система повинна дозволяти:

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

Головний принцип. По кожному документу має бути видно: хто створив, хто погодив, хто відхилив, які коментарі були залишені, яка версія файлу погоджувалась, коли документ був підписаний і хто має право його переглядати.

Реальний бізнес-контекст

Підприємство щодня працює з великою кількістю документів:

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

Перед підписанням такі документи часто мають пройти погодження кількома підрозділами:

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

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

Основний бізнес-процес

Типовий процес візування документа виглядає так:

1. автор створює документ у системі;
2. обирає тип документа;
3. завантажує файл;
4. обирає маршрут погодження;
5. система призначає учасників маршруту;
6. документ переходить у статус «На погодженні»;
7. перший учасник погоджує або відхиляє документ;
8. якщо документ погоджено — він переходить до наступного учасника;
9. якщо документ відхилено — повертається автору на доопрацювання;
10. автор завантажує нову версію файлу;
11. погодження запускається повторно;
12. після всіх погоджень документ переходить на підпис;
13. підписант підписує документ;
14. система формує фінальний PDF або лог погодження;
15. документ переходить в архів.

Основні об’єкти модуля

Об’єкт	Призначення
Документи	Основні файли та картки документів
Типи документів	Класифікація документів
Маршрути візування	Правила проходження документа
Шаблони маршрутів	Типові маршрути для різних документів
Учасники візування	Користувачі, які погоджують або підписують документ
Етапи погодження	Послідовні або паралельні кроки маршруту
Версії документа	Історія змін файлу
Коментарі	Обговорення, зауваження і причини відхилення
Підписи	Фіксація погодження або фінального підпису
Сповіщення	Повідомлення про дії та строки
Журнал аудиту	Повна історія дій з документом
Архів	Завершені або скасовані документи

Довідник «Типи документів»

Тип документа визначає правила його обробки й маршрут погодження.

Приклади типів документів

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

Поля типу документа

Поле	Опис
Назва типу	Наприклад: Договір, Акт, Наказ
Опис	Коротке пояснення
Шаблон маршруту	Типовий маршрут погодження
Потребує фінального підпису	Так або ні
Потребує юридичної перевірки	Так або ні
Потребує фінансової перевірки	Так або ні
Статус	Активний або архівний

Довідник «Ролі учасників візування»

Роль визначає функцію учасника в маршруті.

Приклади ролей

• автор документа;
• підготовка документа;
• керівник підрозділу;
• перевірка юриста;
• перевірка фінансиста;
• перевірка бухгалтерії;
• перевірка служби безпеки;
• погодження керівника;
• фінальне погодження;
• підпис генерального директора;
• підпис контрагента;
• архіваріус.

Поля ролі

Поле	Опис
Назва ролі	Назва ролі в маршруті
Тип дії	Погодження, перевірка, підпис, перегляд
Обов’язковість	Обов’язкова або опціональна роль
Опис	Пояснення відповідальності

База «Документи»

Документ — це основна сутність модуля.

Колонки бази документів

Колонка	Опис
Назва документа	Назва або тема документа
Тип документа	Договір, акт, наказ тощо
Автор	Хто створив документ
Поточний етап	На якому кроці погодження
Статус	Чернетка, на погодженні, підписано, відхилено
Дата створення	Коли створено
Дата завершення	Коли погодження завершено
Файл	Поточна версія документа

Поля документа

Поле	Опис
Номер документа	Внутрішній реєстраційний номер
Назва документа	Назва
Тип документа	Тип із довідника
Автор	Користувач, який створив документ
Підрозділ	Підрозділ автора
Контрагент	Якщо документ зовнішній
Сума документа	Для фінансових документів, опціонально
Валюта	Для договорів, актів, рахунків
Дата створення	Коли створено
Планова дата погодження	До якої дати треба погодити
Поточна версія	Активна версія файлу
Поточний етап	Хто зараз має діяти
Статус	Поточний стан документа
Коментар автора	Супровідний опис

Статуси документа

Статус	Значення
Чернетка	Документ створено, але ще не відправлено
На погодженні	Документ проходить маршрут візування
Повернуто на доопрацювання	Потрібно внести зміни
Відхилено	Документ не погоджено
Очікує підпису	Усі візи отримані, потрібен підпис
Підписано	Документ підписано
Завершено	Процес повністю закрито
Архівовано	Документ перенесено в архів
Скасовано	Процес зупинено

Версії документа

Кожне доопрацювання документа має створювати нову версію.

Поля версії документа

Поле	Опис
Документ	До якого документа належить
Номер версії	v1, v2, v3 тощо
Файл	Завантажений файл
Автор версії	Хто завантажив
Дата завантаження	Коли завантажено
Опис змін	Що змінилось
Активна версія	Так або ні

Правило версійності

Якщо документ було відхилено або повернуто на доопрацювання, автор має завантажити нову версію файлу. Система повинна зберегти попередні версії для аудиту.

База «Шаблони маршрутів»

Шаблон маршруту — це типовий порядок погодження для певного типу документа.

Приклад маршруту для договору

1. автор;
2. керівник підрозділу;
3. юрист;
4. фінансист;
5. бухгалтерія;
6. директор;
7. підписант.

Приклад маршруту для наказу

1. автор;
2. керівник підрозділу;
3. HR;
4. юрист;
5. директор.

Поля шаблону маршруту

Поле	Опис
Назва шаблону	Наприклад: Договір стандартний
Тип документа	До якого типу застосовується
Опис	Коротке пояснення
Тип маршруту	Послідовний, паралельний, змішаний
Статус	Активний або архівний

База «Маршрути візування»

Маршрут візування — це конкретний шлях погодження конкретного документа.

Поля маршруту

Поле	Опис
Документ	Документ, що погоджується
Шаблон маршруту	На основі якого шаблону створено
Тип маршруту	Послідовний, паралельний, змішаний
Дата запуску	Коли маршрут стартував
Дата завершення	Коли завершився
Статус	Активний, завершений, відхилений, скасований

Етапи маршруту

Етап — це окремий крок погодження.

Поля етапу маршруту

Поле	Опис
Маршрут	До якого маршруту належить
Номер етапу	Порядок виконання
Роль	Роль учасника
Учасник	Конкретний користувач
Тип дії	Погодити, перевірити, підписати
Обов’язковий	Так або ні
Строк виконання	Дедлайн етапу
Статус	Очікує, погоджено, відхилено, делеговано, прострочено
Дата дії	Коли виконано
Коментар	Коментар учасника

Послідовний маршрут

Кожен наступний учасник отримує документ тільки після погодження попереднім.

Паралельний маршрут

Кілька учасників погоджують документ одночасно. Документ переходить далі, коли всі обов’язкові учасники виконали дію.

Змішаний маршрут

Частина етапів виконується послідовно, частина — паралельно.

Дії учасника погодження

Учасник маршруту може виконати одну з дій:

• погодити;
• погодити з коментарем;
• відхилити;
• повернути на доопрацювання;
• делегувати;
• підписати;
• переглянути;
• скасувати, якщо має права.

Погодження документа

При погодженні система повинна:

• зафіксувати користувача;
• зафіксувати дату й час;
• зафіксувати версію документа;
• зберегти коментар;
• змінити статус етапу на «Погоджено»;
• передати документ на наступний етап.

Відхилення документа

При відхиленні система повинна:

• вимагати обов’язковий коментар;
• зафіксувати користувача;
• зафіксувати дату й час;
• зафіксувати версію документа;
• змінити статус документа на «Відхилено» або «Повернуто на доопрацювання»;
• повідомити автора.

Повернення на доопрацювання

Якщо документ повернуто на доопрацювання:

• автор отримує сповіщення;
• автор бачить коментарі;
• автор завантажує нову версію;
• система зберігає попередню версію;
• погодження може стартувати заново або з певного етапу.

Підпис документів

Підпис — це фінальна дія або окремий етап маршруту.

Варіанти підпису

• простий підпис через пароль K2 ERP;
• підтвердження через одноразовий код, опціонально;
• електронний підпис через зовнішній сервіс, опціонально;
• інтеграція з Дія.Підпис, опціонально;
• завантаження підписаного PDF, якщо підпис відбувся поза системою.

Поля підпису

Поле	Опис
Документ	Що підписується
Версія документа	Яка версія підписана
Підписант	Хто підписав
Тип підпису	Пароль, ЕЦП, зовнішній сервіс
Дата і час підпису	Коли підписано
Статус	Успішно, помилка, скасовано
Технічні дані	Hash, ідентифікатор підпису, якщо є

Коментарі

Коментарі потрібні для пояснення рішень.

Поля коментаря

Поле	Опис
Документ	До якого документа належить
Етап	До якого етапу належить
Автор коментаря	Хто залишив
Текст коментаря	Суть зауваження
Дата і час	Коли залишено
Тип	Загальний, зауваження, причина відхилення, службовий

Контроль строків погодження

Система має контролювати дедлайни погодження.

Правила контролю строків

• для документа може бути загальний строк погодження;
• для кожного етапу може бути окремий строк;
• прострочений етап підсвічується;
• учасник отримує нагадування;
• керівник бачить прострочені документи;
• система може автоматично ескалювати прострочення.

Делегування

Делегування дозволяє передати погодження іншому користувачу.

Поля делегування

Поле	Опис
Документ	Який документ делеговано
Початковий учасник	Хто мав погоджувати
Новий учасник	Кому передано
Причина	Чому делеговано
Дата делегування	Коли виконано
Статус	Активне, завершене, скасоване

Сповіщення

Система має надсилати сповіщення користувачам.

Події для сповіщень

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

Документи і PDF-форми

Система має формувати PDF-документи.

Приклади PDF-документів

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

Лог візування

Лог візування має містити:

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

Особистий кабінет користувача

Користувач у кабінеті має бачити:

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

Панель адміністратора

Адміністратор має бачити:

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

Звіт «Документи за статусами»

У звіті потрібно відображати:

• статус документа;
• кількість документів;
• типи документів;
• відповідальних користувачів.

Звіт «Документи на погодженні»

У звіті потрібно відображати:

• документ;
• тип;
• автора;
• поточний етап;
• поточного погоджувача;
• строк погодження;
• кількість днів у роботі.

Звіт «Прострочені погодження»

У звіті потрібно відображати:

• документ;
• етап;
• відповідального учасника;
• дедлайн;
• кількість днів прострочення;
• статус.

Звіт «Історія погоджень»

У звіті потрібно відображати:

• документ;
• учасника;
• роль;
• дію;
• дату і час;
• коментар;
• версію документа.

Звіт «Ефективність погодження»

У звіті потрібно відображати:

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

AJAX-інтерактив

Інтерфейс має працювати швидко й без перезавантаження сторінок.

Через AJAX мають працювати:

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

Логування змін

Модуль повинен фіксувати всі важливі дії.

Журнал змін має зберігати:

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

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

Модуль має підтримувати рольову модель.

Роль	Можливості
Автор документа	Створює документ, завантажує файл, запускає погодження, доопрацьовує документ
Погоджувач	Переглядає документ, погоджує, відхиляє, коментує
Юрист	Погоджує юридичні документи, залишає зауваження
Фінансист	Погоджує фінансові умови, суми, платежі
Керівник	Погоджує документи свого підрозділу, бачить прострочення
Підписант	Виконує фінальний підпис
Архіваріус	Переносить завершені документи в архів
Адміністратор системи	Налаштовує типи документів, маршрути, ролі, права й шаблони

Технічні вимоги

Параметр	Опис
Бекенд	K2 Cloud ERP на Python або PHP
База даних	PostgreSQL або MySQL
Фронтенд	HTML5, JavaScript
AJAX	Fetch API або Axios
UI-компоненти	DataTables для документів і маршрутів; Select2 для пошуку документів, ролей і користувачів
Файли	Завантаження PDF, DOCX, XLSX, зображень та інших форматів
Версії	Збереження всіх версій документа
Підпис	Пароль K2 ERP, одноразовий код або інтеграція з ЕЦП, опціонально
Друк	PDF-лог візування і фінальний документ
Експорт	Excel або PDF для реєстрів і звітів
Безпека	Рольовий доступ, журнал аудиту, обмеження доступу до документів

Рекомендовані сутності бази даних

Для реалізації задачі доцільно передбачити такі сутності:

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

Практичне завдання

У межах атестації потрібно продемонструвати робочий сценарій.

Мінімальний сценарій:

1. створити тип документа;
2. створити ролі візування;
3. створити шаблон маршруту;
4. створити документ;
5. завантажити файл документа;
6. створити маршрут погодження;
7. запустити погодження;
8. виконати погодження першим учасником;
9. виконати відхилення другим учасником з коментарем;
10. повернути документ автору на доопрацювання;
11. завантажити нову версію документа;
12. повторно запустити погодження;
13. погодити документ усіма учасниками;
14. виконати фінальний підпис;
15. сформувати PDF-лог візування;
16. перевести документ у статус «Завершено»;
17. архівувати документ;
18. сформувати звіт по погоджених документах;
19. перевірити журнал змін і права доступу.

Критерії оцінювання

Критерій	Бали	Що перевіряється
Реалізація обігу документів і візування	20	Документи, типи, файли, версії, статуси, запуск погодження
Облік маршруту погодження і підписів	20	Шаблони маршрутів, етапи, ролі, учасники, погодження, відхилення, підпис
Фінальний аудит змін	20	Журнал дій, версії, коментарі, хто і коли погодив, PDF-лог візування
Інтерактивність через AJAX і зручність в роботі	20	AJAX-погодження, коментарі, фільтри, оновлення статусів, кабінет користувача
Інтеграція з електронним підписом	20	Простий підпис, ЕЦП або підготовлена архітектура для інтеграції із зовнішнім сервісом
Разом	100	Максимальна оцінка

Шкала оцінювання

Бали	Рівень	Опис
90–100	Відмінно	Модуль повністю працює: документи, маршрути, версії, погодження, відхилення, підпис, PDF-лог, аудит і звіти реалізовані коректно
75–89	Добре	Основна логіка працює, є незначні недоліки, які не руйнують процес візування
60–74	Зараховано	Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання
0–59	Не зараховано	Відсутня критична логіка: документи, маршрути, погодження, версії, підпис або аудит

Критичні помилки

Критичними помилками вважаються ситуації, коли:

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

Умова складання. Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл візування: документ → файл → маршрут → погодження → відхилення → нова версія → повторне погодження → підпис → PDF-лог → архів.

Очікуваний результат

У результаті виконання атестаційного завдання має бути створений модуль електронного візування та погодження документів у K2 ERP.

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

Примітка

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

Якісна система візування зменшує затримки, прибирає хаос у погодженнях, зберігає історію рішень і допомагає юридично фіксувати факт погодження або підпису.

Коротко

Питання	Відповідь
Що потрібно створити?	Модуль електронного візування і погодження документів
Які довідники потрібні?	Типи документів, ролі візування, шаблони маршрутів
Який головний процес?	Документ → маршрут → погодження → підпис → архів
Що потрібно контролювати?	Версії, статуси, коментарі, строки, підписи, доступ, аудит
Які документи потрібні?	PDF-лог візування, карта погодження, фінальний підписаний документ
Які звіти потрібні?	Документи за статусами, на погодженні, прострочені, історія погоджень, ефективність
Що є критичною вимогою?	Кожне погодження, відхилення, підпис і зміна версії мають логуватися
Що бажано додати?	ЕЦП, Дія.Підпис, делегування, SLA, ескалації, кабінет користувача

Див. також

• K2 ERP
• K2 ERP
• Атестаційні завдання K2 ERP
• Веб-архів документів
• Система контролю версій
• Документообіг
• Договір
• CRM
• Особистий кабінет
• Права доступу
• AJAX