Атестаційні завдання K2 ERP/IT компанія
Атестаційне завдання K2 ERP — IT компанія — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля обліку клієнтів, договорів, проєктів, команд, задач, витраченого часу, бюджетів, рахунків, оплат і звітності для IT-компанії.
Модуль має забезпечувати повний цикл роботи IT-компанії: клієнт → договір → проєкт → команда → задачі → облік часу → етапи робіт → рахунок → оплата → фінансовий звіт → аналітика ефективності.
Коротко. Потрібно реалізувати модуль IT-компанії: клієнти, договори, проєкти, команди, задачі, Kanban, time tracking, бюджети, етапи, рахунки, оплати, кабінет співробітника, кабінет клієнта, сповіщення, звіти й AJAX-інтерактив.
Назва завдання
Модуль обліку проєктів, задач, клієнтів, контрактів і фінансів для IT-компанії.
Мета завдання
Мета завдання — створити в K2 ERP модуль для автоматизації управління IT-компанією.
Система повинна дозволяти:
- вести базу клієнтів;
- вести договори з клієнтами;
- вести типи проєктів;
- створювати проєкти;
- призначати менеджерів проєктів;
- формувати команди;
- створювати задачі;
- призначати виконавців;
- вести статуси задач;
- вести пріоритети задач;
- вести облік витраченого часу;
- планувати дедлайни;
- контролювати бюджет;
- рахувати вартість погодинної роботи;
- вести фіксовані бюджети;
- формувати рахунки;
- фіксувати часткові й повні оплати;
- контролювати борги клієнтів;
- формувати звіти по проєктах, задачах, часу, фінансах і співробітниках;
- підтримувати особистий кабінет співробітника;
- підтримувати особистий кабінет клієнта, якщо потрібно;
- надсилати сповіщення про дедлайни, задачі та рахунки.
Головний принцип. Керівник IT-компанії має бачити, які проєкти виконуються, хто над чим працює, скільки часу витрачено, що вже можна виставити клієнту в рахунок і які задачі ризикують не вкластися в дедлайн.
Реальний бізнес-контекст
IT-компанія виконує проєкти для клієнтів.
Типові напрями роботи:
- веб-розробка;
- мобільні додатки;
- ERP-системи;
- CRM-системи;
- SaaS-платформи;
- інтеграції з API;
- технічна підтримка;
- DevOps;
- UI/UX-дизайн;
- тестування;
- бізнес-аналітика;
- супровід існуючих систем.
Компанія може працювати за різними моделями оплати:
- фіксована ціна;
- погодинна оплата;
- абонентська підтримка;
- оплата за етапами;
- змішана модель;
- передоплата;
- післяплата.
Основний бізнес-процес
Типовий процес роботи IT-компанії виглядає так:
- менеджер створює клієнта;
- укладається договір;
- створюється проєкт;
- визначається тип оплати;
- призначається менеджер проєкту;
- формується команда;
- створюються задачі;
- задачі призначаються виконавцям;
- співробітники фіксують витрачений час;
- менеджер контролює статуси, дедлайни й бюджет;
- система формує звіти по часу;
- створюється рахунок клієнту;
- клієнт оплачує повністю або частково;
- система фіксує оплату й борг;
- керівництво переглядає фінансову аналітику.
Основні об’єкти модуля
| Об’єкт | Призначення |
|---|---|
| Клієнти | Замовники IT-послуг |
| Договори | Умови співпраці з клієнтами |
| Проєкти | Роботи, які виконує компанія |
| Команди | Співробітники, залучені до проєктів |
| Задачі | Конкретні одиниці роботи |
| Time tracking | Облік фактично витраченого часу |
| Етапи проєкту | Milestones або частини робіт |
| Бюджети | Планові та фактичні витрати |
| Рахунки | Документи на оплату |
| Оплати | Фактичні платежі клієнтів |
| Сповіщення | Повідомлення про задачі, дедлайни й рахунки |
| Звіти | Аналітика по проєктах, фінансах, задачах і співробітниках |
Довідник «Клієнти»
Клієнти — це компанії або фізичні особи, які замовляють IT-послуги.
Поля клієнта
| Поле | Опис |
|---|---|
| Назва компанії або ПІБ | Найменування клієнта |
| Тип клієнта | Фізична особа, ФОП, юридична особа |
| Контактна особа | Представник клієнта |
| Основна електронна адреса | |
| Телефон | Контактний номер |
| Країна / місто | Локація клієнта |
| Валюта розрахунків | UAH, USD, EUR або інша |
| Статус | Активний, потенційний, архівний |
| Коментар | Внутрішня примітка менеджера |
Довідник «Договори»
Договір визначає умови співпраці з клієнтом.
Поля договору
| Поле | Опис |
|---|---|
| Номер договору | Унікальний номер |
| Клієнт | З ким укладено договір |
| Дата договору | Дата підписання |
| Дата початку | Початок дії |
| Дата завершення | Завершення дії, якщо є |
| Тип оплати | Fixed Price, Time & Material, Retainer, Support |
| Валюта | Валюта розрахунків |
| Ставка за годину | Для погодинних проєктів |
| Фіксований бюджет | Для fixed price |
| Статус | Активний, завершений, призупинений, розірваний |
| Файл договору | PDF або скан |
Довідник «Типи проєктів»
Типи проєктів потрібні для класифікації робіт.
Приклади типів проєктів
- веб-розробка;
- мобільна розробка;
- ERP-системи;
- CRM-системи;
- SaaS;
- технічна підтримка;
- DevOps;
- UI/UX-дизайн;
- тестування;
- інтеграції;
- консалтинг;
- інше.
База «Проєкти»
Проєкт — це основна одиниця роботи IT-компанії.
Колонки бази проєктів
| Колонка | Опис |
|---|---|
| Назва проєкту | Назва роботи або продукту |
| Клієнт | Замовник |
| Тип проєкту | Веб, мобільний, ERP, CRM тощо |
| Дата початку | Коли стартує проєкт |
| Планова дата завершення | Очікуваний дедлайн |
| Фактична дата завершення | Коли завершено |
| Менеджер проєкту | Відповідальний PM |
| Бюджет | Фіксований або погодинний |
| Статус | Новий, в процесі, завершений, скасований |
Поля проєкту
| Поле | Опис |
|---|---|
| Назва проєкту | Назва проєкту |
| Клієнт | Замовник |
| Договір | Договір, за яким виконується робота |
| Тип проєкту | Категорія проєкту |
| Опис | Короткий опис задач і цілей |
| Менеджер проєкту | Відповідальний керівник |
| Дата початку | Початок роботи |
| Планова дата завершення | Плановий дедлайн |
| Фактична дата завершення | Заповнюється після завершення |
| Модель оплати | Fixed Price, Time & Material, Retainer |
| Бюджет | Планова сума |
| Статус | Поточний стан проєкту |
Статуси проєкту
| Статус | Значення |
|---|---|
| Новий | Проєкт створено, робота ще не почалась |
| Планування | Формуються задачі, команда і бюджет |
| В процесі | Активна розробка |
| На паузі | Роботу тимчасово зупинено |
| На прийманні | Очікується перевірка клієнтом |
| Завершений | Проєкт виконано |
| Скасований | Проєкт припинено |
Команда проєкту
Проєкт може мати кількох учасників.
Ролі в команді
- Project Manager;
- Business Analyst;
- Team Lead;
- Backend Developer;
- Frontend Developer;
- Fullstack Developer;
- Mobile Developer;
- QA Engineer;
- UI/UX Designer;
- DevOps Engineer;
- Support Engineer;
- Content Manager;
- інші ролі.
Поля учасника команди
| Поле | Опис |
|---|---|
| Проєкт | До якого проєкту залучено |
| Співробітник | Учасник команди |
| Роль | Роль у проєкті |
| Ставка за годину | Для розрахунку собівартості або рахунків |
| Дата початку | Коли підключено до проєкту |
| Дата завершення | Коли завершив роботу |
| Статус | Активний або завершив участь |
База «Задачі проєкту»
Задача — це конкретна одиниця роботи в межах проєкту.
Колонки задач
| Колонка | Опис |
|---|---|
| Проєкт | До якого проєкту належить |
| Назва задачі | Коротка назва |
| Виконавець | Хто виконує |
| Пріоритет | Низький, середній, високий, критичний |
| Оцінка часу | Планова оцінка в годинах |
| Фактичний час | Скільки витрачено |
| Дедлайн | Коли задача має бути завершена |
| Статус | Нове, в роботі, на перевірці, завершено |
Поля задачі
| Поле | Опис |
|---|---|
| Проєкт | Проєкт задачі |
| Етап | Milestone або етап, якщо є |
| Назва задачі | Назва |
| Опис | Детальний опис роботи |
| Тип задачі | Feature, Bug, Task, Improvement, Support |
| Пріоритет | Низький, середній, високий, критичний |
| Постановник | Хто створив |
| Виконавець | Хто відповідає |
| Дата початку | Плановий старт |
| Дедлайн | Планове завершення |
| Оцінка часу | Планові години |
| Фактичний час | Сума time tracking записів |
| Статус | Поточний стан |
Типи задач
- Feature;
- Bug;
- Task;
- Improvement;
- Support;
- Research;
- Design;
- Testing;
- DevOps;
- Documentation.
Статуси задач
| Статус | Значення |
|---|---|
| Нове | Задачу створено |
| Заплановано | Задача взята в план |
| В роботі | Виконавець працює |
| Заблоковано | Є блокер |
| На перевірці | Очікує review або QA |
| Повернуто | Потрібне доопрацювання |
| Завершено | Роботу виконано |
| Скасовано | Задача більше не актуальна |
Kanban-дошка, опціонально
Для зручності можна реалізувати Kanban-дошку.
Колонки Kanban
- Нове;
- Заплановано;
- В роботі;
- На перевірці;
- Завершено;
- Скасовано.
Функціонал:
- Drag & Drop задач між статусами;
- AJAX-оновлення статусу;
- фільтр по проєкту;
- фільтр по виконавцю;
- фільтр по пріоритету.
Облік часу — Time tracking
Time tracking потрібен для контролю фактичних витрат часу і формування рахунків за погодинною моделлю.
Поля запису часу
| Поле | Опис |
|---|---|
| Співробітник | Хто працював |
| Проєкт | До якого проєкту належить час |
| Задача | До якої задачі належить час |
| Дата | Коли виконувалась робота |
| Час початку | Початок роботи |
| Час завершення | Кінець роботи |
| Кількість годин | Автоматично або вручну |
| Опис роботи | Що було зроблено |
| Статус | Чернетка, підтверджено, відхилено |
| Затвердив | Менеджер, який підтвердив час |
Варіанти фіксації часу
- ручне введення годин;
- таймер старт / стоп;
- імпорт із зовнішньої системи, опціонально;
- підтвердження менеджером;
- заборона редагування після затвердження.
Формула погодинного рахунку
Сума до оплати = Підтверджені години × Погодинна ставка
Етапи проєкту
Етапи потрібні для планування робіт і виставлення рахунків по частинах.
Поля етапу
| Поле | Опис |
|---|---|
| Проєкт | До якого проєкту належить |
| Назва етапу | Наприклад: MVP, Дизайн, Розробка, Тестування |
| Планова дата початку | Коли має стартувати |
| Планова дата завершення | Коли має завершитись |
| Бюджет етапу | Сума або години |
| Статус | Заплановано, в роботі, завершено, скасовано |
Фінанси
Фінансовий блок має підтримувати різні моделі розрахунків.
Моделі оплати
| Модель | Опис |
|---|---|
| Fixed Price | Фіксована ціна за проєкт або етап |
| Time & Material | Оплата за фактично витрачений час |
| Retainer | Щомісячна абонентська плата |
| Support | Оплата технічної підтримки |
| Mixed | Комбінована модель |
Рахунки
Рахунки можуть формуватися:
- за весь проєкт;
- за етап;
- за місяць;
- за підтверджені години;
- за абонентську підтримку;
- за додаткові роботи.
Поля рахунку
| Поле | Опис |
|---|---|
| Номер рахунку | Унікальний номер |
| Клієнт | Кому виставлено |
| Проєкт | За який проєкт |
| Етап | Якщо рахунок за етап |
| Період | Якщо рахунок за місяць або період |
| Модель оплати | Fixed, Hourly, Retainer |
| Сума | Сума до оплати |
| Валюта | UAH, USD, EUR |
| Оплачено | Скільки вже сплачено |
| Борг | Залишок |
| Статус | Очікує оплату, частково оплачено, оплачено, прострочено, скасовано |
Оплати
Система має підтримувати повну і часткову оплату.
Поля оплати
| Поле | Опис |
|---|---|
| Клієнт | Хто оплатив |
| Рахунок | За який рахунок оплата |
| Дата оплати | Коли отримано кошти |
| Сума | Сума платежу |
| Валюта | Валюта оплати |
| Спосіб оплати | Банківський переказ, карта, PayPal, інше |
| Статус | Успішно, очікує, помилка, повернення |
| Коментар | Примітка бухгалтера |
Бюджет і контроль перевитрат
Система має показувати план і факт.
Контроль бюджету включає
- плановий бюджет проєкту;
- фактично витрачений час;
- фактичну собівартість;
- виставлено клієнту;
- оплачено клієнтом;
- борг;
- маржинальність, опціонально.
Сповіщення
Система має надсилати або показувати нагадування.
Події для сповіщень
- створено нову задачу;
- задачу призначено виконавцю;
- наближається дедлайн задачі;
- дедлайн задачі прострочено;
- проєкт наближається до дедлайну;
- перевищено оцінку часу задачі;
- перевищено бюджет проєкту;
- рахунок виставлено;
- рахунок прострочено;
- оплата отримана;
- клієнт залишив коментар або фідбек.
Особистий кабінет співробітника
Співробітник у кабінеті має бачити:
- свої задачі;
- задачі на сьогодні;
- задачі з простроченим дедлайном;
- таймер обліку часу;
- історію своїх time tracking записів;
- коментарі до задач;
- статуси задач;
- сповіщення.
Особистий кабінет клієнта
Кабінет клієнта є опціональним, але бажаним.
Клієнт у кабінеті може бачити:
- список своїх проєктів;
- загальний статус проєкту;
- етапи робіт;
- задачі, відкриті для клієнта;
- рахунки;
- оплати;
- документи;
- можливість залишити фідбек;
- можливість завантажити PDF-рахунок або акт.
Документи
Система має формувати PDF-документи.
Приклади документів
- рахунок на оплату;
- акт виконаних робіт;
- звіт по витраченому часу;
- звіт по проєкту;
- фінансовий звіт;
- комерційна пропозиція, опціонально;
- звіт для клієнта за місяць.
Звіти
Звіт «Проєкти за період»
У звіті потрібно відображати:
- проєкт;
- клієнта;
- менеджера;
- статус;
- плановий бюджет;
- фактичний час;
- виставлено рахунків;
- оплачено;
- борг.
Звіт «Задачі по проєктах»
У звіті потрібно відображати:
- проєкт;
- кількість задач;
- відкриті задачі;
- завершені задачі;
- прострочені задачі;
- задачі по виконавцях.
Звіт «Time tracking»
У звіті потрібно відображати:
- співробітника;
- проєкт;
- задачу;
- дату;
- кількість годин;
- статус підтвердження;
- суму для виставлення клієнту, якщо застосовується.
Звіт «Фінанси по клієнтах»
У звіті потрібно відображати:
- клієнта;
- кількість проєктів;
- виставлено рахунків;
- оплачено;
- борг;
- валюта;
- остання дата оплати.
Звіт «Ефективність співробітників»
У звіті потрібно відображати:
- співробітника;
- кількість задач;
- завершені задачі;
- фактичні години;
- прострочені задачі;
- відсоток виконання вчасно.
Звіт «Прибутковість проєктів»
Опціонально у звіті потрібно відображати:
- бюджет проєкту;
- дохід;
- собівартість;
- витрати часу;
- маржу;
- відхилення від плану.
AJAX-інтерактив
Інтерфейс має працювати швидко й без перезавантаження сторінок.
Через AJAX мають працювати:
- пошук клієнтів;
- створення проєкту;
- створення задачі;
- зміна статусу задачі;
- призначення виконавця;
- запуск і зупинка таймера;
- додавання time tracking запису;
- підтвердження часу менеджером;
- фільтрація задач;
- оновлення Kanban-дошки;
- формування рахунку;
- фіксація оплати;
- фільтрація звітів;
- оновлення кабінету співробітника;
- оновлення кабінету клієнта.
Логування змін
Модуль повинен фіксувати ключові дії.
Журнал змін має зберігати:
- хто створив клієнта;
- хто створив договір;
- хто створив проєкт;
- хто змінив статус проєкту;
- хто додав учасника команди;
- хто створив задачу;
- хто змінив виконавця;
- хто змінив статус задачі;
- хто додав time tracking запис;
- хто змінив або затвердив час;
- хто сформував рахунок;
- хто зафіксував оплату;
- хто змінив бюджет;
- хто експортував звіт;
- дату й час дії;
- старе та нове значення, якщо це можливо.
Права доступу
Модуль має підтримувати рольову модель.
| Роль | Можливості |
|---|---|
| Співробітник | Бачить свої задачі, фіксує час, коментує задачі |
| Project Manager | Керує проєктами, командами, задачами, дедлайнами і підтверджує час |
| Team Lead | Керує задачами команди, переглядає time tracking учасників |
| Бухгалтер | Формує рахунки, фіксує оплати, бачить фінансові звіти |
| Клієнт | Переглядає свої проєкти, рахунки, документи і статуси, якщо кабінет реалізовано |
| Керівник | Бачить усі проєкти, фінанси, завантаженість і ефективність |
| Адміністратор системи | Налаштовує довідники, права, шаблони документів і службові параметри |
Технічні вимоги
| Параметр | Опис |
|---|---|
| Бекенд | K2 Cloud ERP на Python або PHP |
| База даних | PostgreSQL або MySQL |
| Фронтенд | HTML5, JavaScript |
| AJAX | Fetch API або Axios |
| UI-компоненти | DataTables для проєктів, задач, часу і фінансів; Select2 для пошуку клієнтів, проєктів і співробітників |
| Календар | FullCalendar для дедлайнів задач і проєктів |
| Kanban | Drag & Drop дошка задач, опціонально |
| Друк | PDF-рахунки, акти, звіти |
| Експорт | Excel або PDF для звітів |
| Сповіщення | Email або внутрішні повідомлення |
Рекомендовані сутності бази даних
Для реалізації задачі доцільно передбачити такі сутності:
- клієнти;
- договори;
- типи проєктів;
- проєкти;
- команди проєктів;
- співробітники;
- ролі в команді;
- етапи проєктів;
- задачі;
- статуси задач;
- пріоритети задач;
- time tracking записи;
- рахунки;
- позиції рахунків;
- оплати;
- бюджети;
- сповіщення;
- документи;
- журнал змін;
- права доступу;
- звіти.
Практичне завдання
У межах атестації потрібно продемонструвати робочий сценарій.
Мінімальний сценарій:
- створити клієнта;
- створити договір;
- створити тип проєкту;
- створити проєкт;
- призначити менеджера проєкту;
- додати команду проєкту;
- створити етап проєкту;
- створити кілька задач;
- призначити виконавців;
- змінити статус задачі на «В роботі»;
- додати time tracking запис;
- підтвердити витрачений час менеджером;
- змінити статус задачі на «Завершено»;
- сформувати звіт по витраченому часу;
- сформувати рахунок клієнту;
- зафіксувати часткову оплату;
- перевірити борг;
- зафіксувати повну оплату;
- сформувати акт або PDF-рахунок;
- сформувати фінансовий звіт;
- перевірити кабінет співробітника;
- перевірити журнал змін.
Критерії оцінювання
| Критерій | Бали | Що перевіряється |
|---|---|---|
| Реалізація бази проєктів, клієнтів і задач | 20 | Клієнти, договори, проєкти, команди, задачі, статуси, пріоритети |
| Управління часом і завданнями | 20 | Time tracking, таймери, підтвердження часу, дедлайни, Kanban, контроль виконання |
| Формування рахунків і фінансовий облік | 20 | Fixed Price, Hourly, Retainer, рахунки, часткові оплати, борги, фінансові звіти |
| Інтерактивність через AJAX і нагадування | 20 | AJAX-оновлення задач, часу, статусів, рахунків, сповіщення про дедлайни й оплату |
| Зручність користування і мобільна адаптивність | 20 | Кабінет співробітника, кабінет клієнта, фільтри, календар, зрозумілий інтерфейс |
| Разом | 100 | Максимальна оцінка |
Шкала оцінювання
| Бали | Рівень | Опис |
|---|---|---|
| 90–100 | Відмінно | Модуль повністю працює: клієнти, договори, проєкти, задачі, time tracking, рахунки, оплати, кабінети й звіти реалізовані коректно |
| 75–89 | Добре | Основна логіка працює, є незначні недоліки, які не руйнують процес управління IT-компанією |
| 60–74 | Зараховано | Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання |
| 0–59 | Не зараховано | Відсутня критична логіка: клієнти, проєкти, задачі, час, рахунки, оплати або звіти |
Критичні помилки
Критичними помилками вважаються ситуації, коли:
- неможливо створити клієнта;
- неможливо створити проєкт;
- проєкт не прив’язується до клієнта;
- неможливо створити задачу;
- задача не прив’язується до проєкту;
- задача не має статусу;
- неможливо призначити виконавця;
- неможливо внести time tracking запис;
- фактичний час не підсумовується по задачі;
- рахунок не формується;
- рахунок не прив’язується до клієнта або проєкту;
- часткова оплата не змінює борг;
- повна оплата не змінює статус рахунку;
- клієнт бачить чужі проєкти або рахунки;
- звіти не відповідають фактичним задачам, часу, рахункам і оплатам;
- зміни задач, часу, рахунків і оплат не логуються.
Умова складання. Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл IT-компанії: клієнт → договір → проєкт → команда → задача → облік часу → рахунок → оплата → звіт.
Очікуваний результат
У результаті виконання атестаційного завдання має бути створений модуль IT-компанії в K2 ERP.
Модуль має підтримувати клієнтів, договори, типи проєктів, проєкти, команди, задачі, статуси, пріоритети, time tracking, етапи, бюджети, рахунки, оплати, борги, документи, кабінет співробітника, кабінет клієнта, сповіщення, звіти, AJAX-інтерактив, журнал змін і рольовий доступ.
Примітка
ERP для IT-компанії є важливим інструментом для прозорого управління проєктами, контролю дедлайнів, обліку часу, виставлення рахунків і фінансової стабільності.
Якісний облік задач, часу і оплат дозволяє керівництву бачити реальну завантаженість команди, прибутковість проєктів і ризики ще до того, як вони стануть критичними.
Коротко
| Питання | Відповідь |
|---|---|
| Що потрібно створити? | Модуль управління IT-компанією |
| Які довідники потрібні? | Клієнти, договори, типи проєктів, співробітники, ролі, статуси задач |
| Який головний процес? | Проєкт → задачі → time tracking → рахунок → оплата |
| Що потрібно контролювати? | Дедлайни, задачі, час, бюджет, рахунки, борги, завантаженість команди |
| Які документи потрібні? | Рахунки, акти, звіти по часу, звіти по проєктах |
| Які звіти потрібні? | Проєкти, задачі, time tracking, фінанси, ефективність співробітників, прибутковість |
| Що є критичною вимогою? | Фактичний час має підсумовуватися по задачах і проєктах та використовуватися для рахунків |
| Що бажано додати? | Kanban, таймер, кабінет клієнта, кабінет співробітника, календар дедлайнів, сповіщення |