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

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

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

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

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

Що має містити договір? Це дає можливість системі визначати, по яких договорах потрібно автоматизовано створювати рахунки. Частина договорів разова, частина діє протягом тривалого часу й передбачає регулярні платежі: абонплату, роялті, оренду, сервісне обслуговування або постійні послуги. ! У шаблоні потрібно підтримати підстановку змінних:

SEO-опис задача моделює роботу компанії, яка має велику кількість договорів із клієнтами, постачальниками, підрядниками, орендарями або партнерами. Це об’єкт обліку, який має контрагента, тип, строки, статус, умови пролонгації, платежі, рахунки, файли, історію змін і відповідальних осіб. Усі важливі зміни по договору потрібно фіксувати в журналі змін.== Очікуваний результат == роботу без перезавантаження сторінок через AJAX; збереження чернеток договорів; вибір контрагента через AJAX-пошук; автоматичний підрахунок сум платежів; автоматичне створення рахунків; контроль строків дії договорів; сповіщення відповідальних менеджерів; масову пролонгацію; прикріплення файлів; лог змін із зазначенням, хто і коли редагував договір. * автоматизовано створити чернетку рахунку на оплату; сформувати номер рахунку на базі номера договору та порядкового номера місяця; пов’язати рахунок із договором; відобразити рахунок у журналі рахунків; не створювати дублікати рахунків за той самий період. {\| class="wikitable" style="width:100%;"
Назва компанії	Офіційна назва контрагента
Тип контрагента	клієнт ERP, постачальник, підрядник або інтегратор
ЄДРПОУ або ІПН	Ідентифікатор контрагента
Контактна особа	Відповідальний представник контрагента
Email для повідомлень	Адреса для рахунків, актів і повідомлень
Телефон	Контактний номер

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

Див. так само

критично. Файл договору не замінює структуровані поля. Типові варіанти: За 30 днів до закінчення договору платформа має створити нагадування.== Акти виконаних робіт ==

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

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

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

Які звіти потрібні?== Додаткові інформаційні дані договору ==

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

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

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

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

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

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

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

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

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

* номер рахунку;

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

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

Контрагент

Вибір через AJAX-пошук

Тип договору

Вибір із довідника типів договорів

Номер договору

Вводиться вручну або генерується автоматизовано

Дата укладання

Дата підписання договору

Дата початку

Початок дії договору

Дата закінчення

Завершення дії договору

Статус

Чернетка, діючий, закінчений, пролонгований, розірваний

Відповідальний менеджер

Працівник, відповідальний за договір

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

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

! Що перевіряється

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

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

! Бали

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

компанія-користувач має багато договорів із клієнтами та підрядниками. Шаблон рахунку має містити: У межах атестації потрібно продемонструвати робочий сценарій.== Сповіщення про закінчення договору ==

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

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

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

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

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

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

У результаті виконання атестаційного задача має бути створений компонент керування договорами в K2 ERP. ! У звіті потрібно відображати: |- | Реалізація журналу договорів | 15 | Пошук, фільтри, статуси, строки, суми, контрагенти, типи договорів |- | Форма створення договору та розрахунки | 20 | Поля договору, пролонгація, періодичність оплат, суми, файли, чернетки |- | Автоматичне створення рахунків | 20 | Рахунки по діючих договорах, відсутність дублів, зв’язок із договором |- | Нотифікації про закінчення договорів | 15 | Нагадування за 30 днів, панель керівника, email відповідальному |- | Формування друкованих шаблонів | 10 | Шаблон договору, рахунок, акт, підстановка змінних |- | Якість структури БД і коду | 20 | Сутності, зв’язки, лог змін, підтримуваність, розділення логіки |- У договорі потрібно передбачити умови пролонгації: ! | Контрагента, тип, номер, строки, статус, суму, пролонгацію, файли й відповідального |- | Що має створюватися автоматизовано? * прикріплення файлу скану підписаного договору у форматі PDF;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|}

Критерій

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

Акт здатна створюватися на підставі договору або рахунку.== Умови пролонгації ==

class="wikitable" style="width:100%;"

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

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

Які довідники потрібні? Значення

Що потрібно створити? * оренда; постійне обслуговування; постачання; аутсорсинг; ліцензійна угода; сервісний договір; інші типи. Рівень
Потребує автоматичного виставлення рахунків	Так / Ні

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

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

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

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

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

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

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

За 30 днів до закінчення договору

Які шаблони потрібні? Об’єкт

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

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

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

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

Рахунок здатна формуватися у PDF або іншому форматі, який застосовують, коли потрібно в K2 ERP. ! SEO-опис

Разом

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

автоматизовано

Договір здатна бути продовжений автоматизовано за заданими правилами

За погодженням

Для продовження потрібне рішення для бізнесу відповідальної особи

Без пролонгації

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

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

користувач системи повинен оперативно бачити ключову інформацію по кожному договору: номер, контрагента, тип, строки, статус, суму та періодичність оплат.== Звіт «Очікувані платежі» == Шаблон договору повинен формуватися у форматі DOCX або PDF. Статус керування договорами — це практична задача; так само реалізовано контролю строків, пролонгацій, автоматичних рахунків, друкованих шаблонів і звітності виступає ключовою рисою перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля обліку договорів забезпечується через Атестаційне задача K2 ERP. Поле Якщо договір передбачає регулярні платежі, потрібно вказати суму платежу та правило формування рахунків. Мінімальний сценарій:

! Бали

! Призначення Умова складання. задача не здатна бути зараховане, якщо платформа не контролює строки дії договорів або не здатна автоматизовано створити рахунок по активному договору з регулярними платежами. Поле Коротко Критично. Якщо платформа не попереджає про закінчення договору, бізнес-середовище ризикує пропустити пролонгацію, втратити клієнта, порушити умови співпраці або не виставити рахунок вчасно. \| Рахунки по діючих договорах із регулярними платежами
Коли має бути нагадування? Усі рахунки, створені на підставі договорів, мають відображатися в журналі рахунків. провідний принцип. Договір у K2 ERP — це не без зусиль файл PDF.== Статуси договору == Мета задача	Питання	Параметр
Бекенд	K2 ERP на Python або PHP
База даних	PostgreSQL або MySQL
Фронтенд	HTML5, JavaScript, AJAX
UI-компоненти	DataTables, Select2 для вибору контрагентів
Друк	Stimulsoft або внутрішній генератор PDF
Файли	Завантаження PDF-сканів договорів і додаткових угод
Нотифікації	Email-повідомлення відповідальним менеджерам

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

Коротко. Потрібно реалізувати компонент. {| class="wikitable" style="width:100%;"

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

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

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

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

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

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

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

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