Атестаційні завдання K2 ERP/Енерго-компанія

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

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

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

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

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

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

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

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

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

Головний принцип. Сума рахунку має формуватися не вручну, а на основі фактичного або нормативного споживання, чинного тарифу і правил нарахування.

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

Енергетична або комунальна компанія постачає клієнтам ресурси:

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

Компанія працює з різними категоріями абонентів:

• фізичні особи;
• юридичні особи;
• ОСББ;
• бюджетні установи;
• комерційні підприємства;
• промислові споживачі.

Компанії потрібно:

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

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

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

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

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

Об’єкт	Призначення
Абоненти	Фізичні та юридичні особи, які споживають ресурси
Договори	Юридична основа надання послуг
Особові рахунки	Облікові рахунки абонентів
Об’єкти підключення	Адреси або об’єкти, де споживається ресурс
Типи ресурсів	Електроенергія, газ, вода, тепло
Тарифні плани	Ціни за одиницю ресурсу
Лічильники	Прилади обліку споживання
Показники	Дані лічильників за період
Нарахування	Розраховані суми до сплати
Рахунки	Документи для оплати
Оплати	Фактичні платежі
Борги	Несплачені суми
Переплати	Надлишкові платежі
Сповіщення	Нагадування про показники, рахунки та борги
Звіти	Аналітика по споживанню, оплатах і боргах

Довідник «Абоненти»

Абонент — це клієнт енергетичної компанії.

Типи абонентів

• фізична особа;
• юридична особа;
• ФОП;
• ОСББ;
• бюджетна установа;
• промисловий споживач.

Поля абонента

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

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

Договір визначає умови надання ресурсу абоненту.

Поля договору

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

Особові рахунки

Особовий рахунок використовується для фінансового обліку абонента.

Поля особового рахунку

Поле	Опис
Номер рахунку	Унікальний номер
Абонент	Власник рахунку
Тип ресурсу	Ресурс, за який ведеться облік
Об’єкт підключення	Адреса споживання
Поточний баланс	Борг або переплата
Статус	Активний, заблокований, архівний

Довідник «Об’єкти підключення»

Один абонент може мати кілька об’єктів підключення.

Приклади об’єктів

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

Поля об’єкта підключення

Поле	Опис
Абонент	Власник або користувач об’єкта
Назва об’єкта	Наприклад: Квартира, Склад №1, Офіс
Адреса підключення	Фактична адреса
Тип об’єкта	Житловий, комерційний, промисловий
Тип ресурсу	Електроенергія, газ, вода, тепло
Потужність / ліміт	Опціонально
Статус	Підключено, призупинено, відключено, архів

Довідник «Типи ресурсів»

Тип ресурсу визначає одиницю виміру і правила обліку.

Типи ресурсів

Ресурс	Одиниця виміру
Електроенергія	кВт⋅год
Газ	м³
Вода	м³
Тепло	Гкал
Гаряча вода	м³

Довідник «Тарифні плани»

Тарифний план визначає ціну одиниці ресурсу за певний період.

Поля тарифного плану

Поле	Опис
Назва тарифу	Наприклад: Населення, Бізнес, Промисловий
Тип ресурсу	Електроенергія, газ, вода, тепло
Категорія абонента	Фізична особа, юридична особа, промисловий споживач
Одиниця виміру	кВт⋅год, м³, Гкал
Ціна за одиницю	Вартість одиниці ресурсу
Дата початку дії	З якої дати тариф чинний
Дата завершення дії	До якої дати тариф чинний
Статус	Активний, архівний

Варіанти тарифікації, опціонально

Система може підтримувати складніші тарифи:

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

База «Лічильники»

Лічильник — це прилад обліку споживання ресурсу.

Поля лічильника

Поле	Опис
Абонент	Власник або користувач
Об’єкт підключення	Де встановлений лічильник
Тип ресурсу	Що обліковує
Номер лічильника	Серійний номер
Модель	Опціонально
Дата встановлення	Коли встановлено
Дата повірки	Дата останньої повірки
Дата наступної повірки	Коли потрібно перевірити
Початковий показник	Показник при встановленні
Місце встановлення	Квартира, щитова, підвал тощо
Статус	Активний, демонтований, на повірці, несправний

База «Показники лічильників»

Показник — це значення лічильника на певну дату.

Поля показника

Поле	Опис
Лічильник	До якого лічильника належить показник
Абонент	Власник лічильника
Дата показника	Коли передано або внесено показник
Період	Місяць або інший обліковий період
Значення	Поточний показник
Попереднє значення	Автоматично з попереднього періоду
Споживання	Різниця між поточним і попереднім значенням
Джерело	Вручну, кабінет абонента, CSV, API
Статус	Новий, перевірено, помилковий, скасований

Розрахунок споживання

Базова формула:

Споживання = Поточний показник - Попередній показник

Якщо поточний показник менший за попередній, система має показати попередження.

Формування рахунків

Рахунок формується на основі споживання і тарифу.

Базова формула

Сума до сплати = Споживання × Тариф

Приклад

• попередній показник: 1200 кВт⋅год;
• поточний показник: 1350 кВт⋅год;
• споживання: 150 кВт⋅год;
• тариф: 4 грн за кВт⋅год;
• сума до сплати: 600 грн.

Поля рахунку

Поле	Опис
Номер рахунку	Унікальний номер
Абонент	Кому виставлено рахунок
Особовий рахунок	Фінансовий рахунок абонента
Об’єкт підключення	За який об’єкт рахунок
Тип ресурсу	Електроенергія, газ, вода, тепло
Період споживання	За який період сформовано
Споживання	Обсяг за період
Тариф	Ціна за одиницю
Сума	Сума до оплати
Оплачено	Скільки вже оплачено
Борг	Залишок до оплати
Статус	Створено, частково оплачено, оплачено, прострочено, скасовано

Статуси рахунку

Статус	Значення
Створено	Рахунок сформовано
Надіслано	Рахунок відправлено абоненту
Очікує оплату	Оплати ще немає
Частково оплачено	Оплачено не всю суму
Оплачено	Рахунок повністю закрито
Прострочено	Термін оплати минув
Скасовано	Рахунок скасовано

Оплати

Система має підтримувати фіксацію платежів.

Способи оплати

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

Поля оплати

Поле	Опис
Абонент	Хто оплатив
Особовий рахунок	На який рахунок зараховано
Рахунок	Який рахунок закривається
Дата оплати	Коли отримано оплату
Сума	Розмір платежу
Спосіб оплати	Готівка, картка, переказ тощо
Статус	Очікує, успішно, помилка, повернення
Коментар	Примітка оператора

Часткова оплата

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

При частковій оплаті:

• сума оплати зменшує борг;
• рахунок отримує статус «Частково оплачено»;
• залишок боргу залишається відкритим.

Переплата

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

Переплату можна:

• залишити на балансі абонента;
• врахувати в наступному рахунку;
• повернути вручну, якщо реалізовано.

Нарахування без показників, опціонально

Якщо показники не передані, система може підтримувати:

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

Особистий кабінет абонента

Абонент повинен мати можливість працювати з власними даними.

У кабінеті абонент бачить

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

Сповіщення

Система має підтримувати SMS або Email-сповіщення.

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

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

Документи

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

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

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

Звіт «Споживання за період»

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

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

Звіт «Рахунки за період»

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

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

Звіт «Оплати за період»

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

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

Звіт «Борги абонентів»

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

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

Звіт «Лічильники на повірку»

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

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

Звіт «Доходи по ресурсах»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметр	Опис
Бекенд	K2 Cloud ERP на Python або PHP
База даних	PostgreSQL або MySQL
Фронтенд	HTML5, JavaScript
AJAX	Fetch API або Axios
UI-компоненти	DataTables для таблиць абонентів, лічильників, показників і рахунків; Select2 для пошуку абонентів, ресурсів і тарифів
Особистий кабінет	Кабінет абонента для передачі показників і перегляду рахунків
Імпорт	CSV-імпорт показників або оплат, опціонально
API	Прийом показників або оплат через API, опціонально
Друк	PDF-рахунки, акти звірки, квитанції, звіти
Експорт	Excel або PDF для звітів
Сповіщення	SMS або Email

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

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

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

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

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

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

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

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

Критерій	Бали	Що перевіряється
Реалізація бази абонентів, лічильників і тарифів	20	Абоненти, договори, особові рахунки, об’єкти підключення, ресурси, тарифи, лічильники
Облік споживання і формування рахунків	20	Показники, попередні і поточні значення, споживання, тариф, нарахування, рахунок
Фінансовий облік оплат і заборгованості	20	Часткові оплати, повні оплати, борги, переплати, статуси рахунків, акти звірки
Генерація документів і інтеграція нагадувань	20	PDF-рахунки, квитанції, акти, SMS/Email-нагадування, кабінет абонента
Інтерактивність через AJAX і мобільна адаптивність	20	AJAX-пошук, внесення показників, розрахунок рахунків, оплати, фільтри, кабінет абонента
Разом	100	Максимальна оцінка

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

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

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

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

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

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

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

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

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

Примітка

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

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

Коротко

Питання	Відповідь
Що потрібно створити?	Модуль обліку енергетичної або комунальної компанії
Які довідники потрібні?	Абоненти, ресурси, тарифи, лічильники, об’єкти підключення
Який головний процес?	Передача показників, розрахунок споживання, рахунок і оплата
Що потрібно контролювати?	Показники, споживання, тарифи, рахунки, борги, переплати, повірки лічильників
Які документи потрібні?	PDF-рахунки, квитанції, акти звірки, повідомлення про борг
Які звіти потрібні?	Споживання, рахунки, оплати, борги, лічильники на повірку, доходи по ресурсах
Що є критичною вимогою?	Рахунок має формуватися на основі споживання і чинного тарифу
Що бажано додати?	Кабінет абонента, онлайн-передачу показників, CSV/API-імпорт, SMS/Email-сповіщення

Див. також

• K2 ERP
• K2 ERP
• Атестаційні завдання K2 ERP
• CRM
• Каса
• Рахунок на оплату
• Особистий кабінет
• Договір
• Білінг
• Лічильник
• Тариф
• AJAX