Атестаційні завдання K2 ERP/Управління договорами

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

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

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

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

Модуль управління договорами компанії.

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

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

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

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

Головний принцип. Договір у K2 ERP — це не просто файл PDF. Це об’єкт обліку, який має контрагента, тип, строки, статус, умови пролонгації, платежі, рахунки, файли, історію змін і відповідальних осіб.

Реалістичний бізнес-процес

Компанія має багато договорів із клієнтами та підрядниками. Частина договорів разова, частина діє протягом тривалого часу й передбачає регулярні платежі: абонплату, роялті, оренду, сервісне обслуговування або постійні послуги.

Для нормальної роботи потрібно не лише зберігати договори, а й контролювати їхній стан:

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

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

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

Довідник «Контрагенти»

Довідник контрагентів зберігає інформацію про компанії або фізичних осіб, з якими укладаються договори.

Мінімальний склад даних:

Поле	Опис
Назва компанії	Офіційна назва контрагента
Тип контрагента	Клієнт, постачальник, підрядник або партнер
ЄДРПОУ або ІПН	Ідентифікатор контрагента
Контактна особа	Відповідальний представник контрагента
Email для повідомлень	Адреса для рахунків, актів і повідомлень
Телефон	Контактний номер

Контрагент має обиратися в договорі через AJAX-пошук або інший зручний механізм швидкого вибору.

Довідник «Типи договорів»

Довідник типів договорів потрібен для класифікації договорів і визначення їхньої поведінки в системі.

Типові варіанти:

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

Для кожного типу договору потрібно передбачити ознаку:

Поле	Значення
Потребує автоматичного виставлення рахунків	Так / Ні

Це дозволяє системі визначати, по яких договорах потрібно автоматично створювати рахунки.

Журнал «Договори»

Журнал договорів має відображати всі договори компанії.

Користувач повинен швидко бачити ключову інформацію по кожному договору: номер, контрагента, тип, строки, статус, суму та періодичність оплат.

Колонки журналу договорів

Колонка	Опис
Номер договору	Унікальний номер договору
Контрагент	Сторона договору
Тип договору	Оренда, постачання, обслуговування, ліцензія тощо
Дата укладання	Дата підписання або створення договору
Дата початку	Початок дії договору
Дата закінчення	Завершення дії договору
Статус	Діючий, закінчений, пролонгований, розірваний
Сума договору	Загальна або періодична сума
Періодичність оплат	Одноразово, щомісяця, щокварталу

Статуси договору

Статус	Значення
Діючий	Договір активний і може використовуватися для рахунків та звітів
Закінчений	Строк дії договору завершено
Пролонгований	Договір продовжено на новий період
Розірваний	Договір припинено достроково
Чернетка	Договір створено, але ще не введено в дію

Функціональність журналу

Журнал договорів має підтримувати:

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

Форма створення договору

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

Заголовок договору

У заголовку договору потрібно передбачити:

Поле	Опис
Контрагент	Вибір через AJAX-пошук
Тип договору	Вибір із довідника типів договорів
Номер договору	Вводиться вручну або генерується автоматично
Дата укладання	Дата підписання договору
Дата початку	Початок дії договору
Дата закінчення	Завершення дії договору
Статус	Чернетка, діючий, закінчений, пролонгований, розірваний
Відповідальний менеджер	Працівник, відповідальний за договір

Умови пролонгації

У договорі потрібно передбачити умови пролонгації:

Варіант	Опис
Автоматично	Договір може бути продовжений автоматично за заданими правилами
За погодженням	Для продовження потрібне рішення відповідальної особи
Без пролонгації	Договір завершується після дати закінчення

Масова пролонгація має дозволяти продовжити групу договорів на новий термін.

Періодичність оплат

У договорі потрібно передбачити періодичність виставлення рахунків.

Типові варіанти:

одноразово;
щомісяця;
щокварталу;
щороку;
вручну.

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

Додаткові дані договору

У формі договору потрібно передбачити:

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

Важливо. Файл договору не замінює структуровані поля. Дати, статус, сума, тип договору й контрагент мають зберігатися окремо, щоб система могла будувати звіти, нагадування та рахунки.

Автоматичне нарахування рахунків по договорах

На початку кожного місяця система має перевіряти всі діючі договори з періодичністю «Щомісяця».

Для кожного такого договору система повинна:

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

Правильна логіка. Автоматичний рахунок має створюватися тільки по активному договору, для якого настав період нарахування і ще немає рахунку за цей період.

Журнал рахунків по договорах

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

У журналі потрібно показувати:

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

Сповіщення про закінчення договору

За 30 днів до закінчення договору система має створити нагадування.

Нагадування повинно:

відображатися у списку «Договори, що закінчуються» у панелі керівника;
надсилатися email відповідальному менеджеру;
містити номер договору, контрагента, дату завершення та відповідального.

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

Шаблон договору

Шаблон договору повинен формуватися у форматі DOCX або PDF.

У шаблоні потрібно підтримати підстановку змінних:

Змінна	Значення
`Шаблон:CONTRACT NUMBER`	Номер договору
`Шаблон:CLIENT NAME`	Назва клієнта або контрагента
`Шаблон:START DATE`	Дата початку
`Шаблон:END DATE`	Дата закінчення
`Шаблон:AMOUNT`	Сума

Також потрібно реалізувати генерацію шаблонного тексту договору на основі введених даних.

Шаблон рахунку

Шаблон рахунку має містити:

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

Рахунок може формуватися у PDF або іншому форматі, який використовується в K2 ERP.

Акти виконаних робіт

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

Акт може створюватися на підставі договору або рахунку.

У ньому потрібно показати:

контрагента;
договір;
період;
перелік послуг;
суму;
реквізити сторін;
місце для підписів.

Звіт «Договори за період»

Звіт має показувати договори за вибраний період.

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

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

Звіт «Очікувані платежі»

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

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

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

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

Функціональні вимоги

Модуль повинен підтримувати:

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

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

Усі важливі зміни по договору потрібно фіксувати в журналі змін.

Журнал має містити:

хто створив договір;
хто змінив договір;
що саме було змінено;
дату й час зміни;
старе значення;
нове значення;
коментар, якщо він був вказаний.

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

Параметр	Опис
Бекенд	K2 ERP на Python або PHP
База даних	PostgreSQL або MySQL
Фронтенд	HTML5, JavaScript, AJAX
UI-компоненти	DataTables, Select2 для вибору контрагентів
Друк	Stimulsoft або внутрішній генератор PDF
Файли	Завантаження PDF-сканів договорів і додаткових угод
Нотифікації	Email-повідомлення відповідальним менеджерам

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

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

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

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

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

Критерій	Бали	Що перевіряється
Реалізація журналу договорів	15	Пошук, фільтри, статуси, строки, суми, контрагенти, типи договорів
Форма створення договору та розрахунки	20	Поля договору, пролонгація, періодичність оплат, суми, файли, чернетки
Автоматичне створення рахунків	20	Рахунки по діючих договорах, відсутність дублів, зв’язок із договором
Нотифікації про закінчення договорів	15	Нагадування за 30 днів, панель керівника, email відповідальному
Формування друкованих шаблонів	10	Шаблон договору, рахунок, акт, підстановка змінних
Якість структури БД і коду	20	Сутності, зв’язки, лог змін, підтримуваність, розділення логіки
Разом	100	Максимальна оцінка

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

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

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

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

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

Умова складання. Завдання не може бути зараховане, якщо система не контролює строки дії договорів або не може автоматично створити рахунок по активному договору з регулярними платежами.

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

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

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

Примітка

Такий модуль є обов’язковим для компаній середнього й великого бізнесу, які працюють із великою кількістю договорів: сервісних компаній, IT-компаній, торговельних мереж, орендодавців, фінансових установ і виробничих підприємств.

Коротко

Питання	Відповідь
Що потрібно створити?	Модуль управління договорами компанії
Які довідники потрібні?	Контрагенти та типи договорів
Що має містити договір?	Контрагента, тип, номер, строки, статус, суму, пролонгацію, файли й відповідального
Що має створюватися автоматично?	Рахунки по діючих договорах із регулярними платежами
Коли має бути нагадування?	За 30 днів до закінчення договору
Які шаблони потрібні?	Договір, рахунок і акт виконаних робіт
Які звіти потрібні?	Договори за період і очікувані платежі
Що є критичною вимогою?	Контроль строків дії договорів і автоматичне створення рахунків

Див. також