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

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

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

!; характеристика

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

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

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

!; Поле

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

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

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

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

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

Коротко. Потрібно реалізувати компонент.; характеристика

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

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

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

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

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

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

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

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

організація має багато договорів із клієнтами та підрядниками.; У звіті потрібно відображати:

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

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

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

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

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

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

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

Назва задача

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

class="wikitable" style="width:100%;" Для нормальної роботи потрібно не лише зберігати договори, а й контролювати їхній стан: Журнал рахунків по договорах платформа повинна дозволяти: У формі договору потрібно передбачити:
Шаблон:CONTRACT NUMBER	Номер договору
Шаблон:CLIENT NAME	Назва клієнта або контрагента
Шаблон:START DATE	Дата початку
Шаблон:END DATE	Дата закінчення
Шаблон:AMOUNT	Сума

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

!; | Договори за період і очікувані платежі |- | Що є собою критичною вимогою?; Максимальна оцінка

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

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

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

|- | Що має створюватися автономно?; !;== Мета задача == |- | Номер договору | Унікальний номер договору |- | Контрагент | Сторона договору |- | Тип договору | Оренда, постачання, обслуговування, ліцензійний пакет тощо |- | Дата укладання | Дата підписання або створення договору |- | Дата початку | Початок дії договору |- | Дата закінчення | Завершення дії договору |- | Статус | Діючий, закінчений, пролонгований, розірваний |- | Сума договору | Загальна або періодична сума |- | Періодичність оплат | Одноразово, щомісяця, щокварталу |}

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

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

задача моделює роботу компанії, яка має велику кількість договорів із клієнтами, постачальниками, підрядниками, орендарями або партнерами.; !; Рахунок має змогу формуватися у PDF або іншому форматі, який застосовують, коли потрібно в K2 ERP.; 100

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

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

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

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

!; У результаті виконання атестаційного задача має бути створений компонент керування договорами в K2 ERP.; Питання Це надає можливість системі визначати, по яких договорах потрібно автономно створювати рахунки.; Поле !;== Журнал «Договори» ==

Звіт має показувати суми платежів по діючих договорах на майбутні місяці.; !; | Договір, рахунок і акт виконаних робіт |- | Які звіти потрібні?; керування договорами — це практична задача; додатково реалізовано контролю строків, пролонгацій, автоматичних рахунків, друкованих шаблонів і звітності виступає ключовою рисою перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля обліку договорів забезпечується через Атестаційне задача K2 ERP.; центральний принцип. Договір у K2 ERP — це не без ускладнень файл PDF.; Рівень

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

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

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

За 30 днів до закінчення договору платформа має створити нагадування.; Для кожного типу договору потрібно передбачити ознаку: Правильна логіка. Автоматичний рахунок має створюватися тільки по активному договору, для якого настав період нарахування і ще немає рахунку за цей період.; !; Дати, статус, сума, тип договору й контрагент мають зберігатися окремо, щоб платформа могла будувати звіти, нагадування та рахунки.; Значення

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

компонент керування договорами компанії.; | Рахунки по діючих договорах із регулярними платежами |- | Коли має бути нагадування?; Призначення

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

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

!; * прикріплення файлу скану підписаного договору у форматі PDF;

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

Критичними помилками вважаються ситуації, коли: Мета задача — створити в K2 ERP компонент для централізованого обліку договорів компанії.; Такий компонент є собою обов’язковим для компаній середнього й великого бізнесу, які працюють із великою кількістю договорів: сервісних компаній, IT-компаній, торговельних мереж, орендодавців, фінансових установ і виробничих підприємств.; {| class="wikitable" style="width:100%;"

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

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

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

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

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

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

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

На початку кожного місяця платформа має перевіряти всі діючі договори з періодичністю «Щомісяця».; Окремо варто відзначити який веде договори, контролює строки дії, зберігає файли, створює рахунки за активними договорами, попереджає про закінчення і формує друковані шаблони й звіти.; !;== Технічні вимоги == істотно. Файл договору не замінює структуровані поля.; !; * контрагенти;

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

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

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

Див.; додатково

Акт має змогу створюватися на підставі договору або рахунку.; Бали Журнал договорів має відображати всі договори компанії.; У межах атестації потрібно продемонструвати робочий сценарій.; {| class="wikitable" style="width:100%;"

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

Форма договору складається із заголовка, умов договору, файлів, налаштувань платежів і службової інформації.; !; {| class="wikitable" style="width:100%;" |-

| Що потрібно створити?;

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

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

Довідник контрагентів зберігає інформацію про компанії або фізичних осіб, з якими укладаються договори.; !; У договорі потрібно передбачити періодичність виставлення рахунків.; | За 30 днів до закінчення договору |- | Які шаблони потрібні?; | компонент керування договорами компанії |-

| Які довідники потрібні?;

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

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

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

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

!; |}

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

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

!;

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

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

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

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

Реалізація журналу договорів	15	Пошук, фільтри, статуси, строки, суми, контрагенти, типи договорів
Форма створення договору та розрахунки	20	Поля договору, пролонгація, періодичність оплат, суми, файли, чернетки
Автоматичне створення рахунків	20	Рахунки по діючих договорах, відсутність дублів, зв’язок із договором
Нотифікації про закінчення договорів	15	Нагадування за 30 днів, панель керівника, email відповідальному
Формування друкованих шаблонів	10	Шаблон договору, рахунок, акт, підстановка змінних
Якість структури БД і коду	20	Сутності, зв’язки, лог змін, підтримуваність, розділення логіки
; Що перевіряється ; характеристика Мінімальний сценарій: Усі важливі зміни по договору потрібно фіксувати в журналі змін.; Об’єкт які договори діють зараз; які завершуються найближчим часом; які договори потрібно пролонгувати; по яких договорах треба виставити рахунок; які суми очікуються в майбутніх періодах; де зберігається підписаний файл договору; хто і коли змінював умови договору.; ; Бали Звіт має показувати договори за вибраний період.; Колонка K2 ERP K2 ERP Атестаційні завдання K2 ERP Управління договорами Контрагенти Рахунок на оплату Акт виконаних робіт Автоматичне нарахування Пролонгація договору Журнал змін Шаблон договору ; class="wikitable" style="width:100%;" одноразово; щомісяця; щокварталу; щороку; вручну.; Значення роботу без перезавантаження сторінок через AJAX; збереження чернеток договорів; вибір контрагента через AJAX-пошук; автоматичний підрахунок сум платежів; автоматичне створення рахунків; контроль строків дії договорів; сповіщення відповідальних менеджерів; масову пролонгацію; прикріплення файлів; лог змін із зазначенням, хто і коли редагував договір.; | Контрагенти та типи договорів Контроль строків дії договорів і автоматичне створення рахунків ;== Колонки журналу договорів == Журнал має містити: Довідник типів договорів потрібен для класифікації договорів і визначення їхньої поведінки в системі.; Журнал договорів має підтримувати: