Атестаційні завдання K2 ERP/Енерго-компанія
Атестаційне завдання K2 ERP — Енерго-компанія — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля обліку абонентів, договорів, об’єктів підключення, лічильників, тарифів, показників споживання, рахунків, оплат, заборгованості, сповіщень і звітності для енергетичної або комунальної компанії.
Модуль має забезпечувати повний цикл роботи постачальника ресурсів: абонент → договір → об’єкт підключення → лічильник → показник → споживання → тариф → нарахування → рахунок → оплата → борг або переплата → звіт.
Коротко. Потрібно реалізувати модуль енергетичної компанії: абоненти, договори, об’єкти підключення, лічильники, ресурси, тарифи, показники, розрахунок споживання, рахунки, оплати, борги, особистий кабінет абонента, сповіщення, документи, звіти й AJAX-інтерактив.
Назва завдання
Модуль обліку абонентів, обсягів споживання енергії, рахунків і платежів для енергетичної компанії.
Мета завдання
Мета завдання — створити в K2 ERP модуль для автоматизації роботи енергетичної або комунальної компанії, яка надає послуги постачання ресурсів.
Система повинна дозволяти:
- вести базу абонентів;
- вести договори;
- вести особові рахунки;
- вести об’єкти підключення;
- вести типи ресурсів;
- вести тарифні плани;
- вести лічильники;
- прив’язувати кілька лічильників до одного абонента;
- реєструвати показники лічильників;
- розраховувати споживання за період;
- автоматично формувати нарахування;
- формувати рахунки;
- фіксувати повну або часткову оплату;
- контролювати борги;
- контролювати переплати;
- підтримувати особистий кабінет абонента;
- приймати показники онлайн;
- надсилати SMS або Email-нагадування;
- формувати PDF-рахунки й акти;
- формувати звіти по споживанню, оплатах, боргах і тарифах.
Головний принцип. Сума рахунку має формуватися не вручну, а на основі фактичного або нормативного споживання, чинного тарифу і правил нарахування.
Реальний бізнес-контекст
Енергетична або комунальна компанія постачає клієнтам ресурси:
- електроенергію;
- газ;
- воду;
- тепло;
- гарячу воду;
- інші комунальні ресурси.
Компанія працює з різними категоріями абонентів:
- фізичні особи;
- юридичні особи;
- ОСББ;
- бюджетні установи;
- комерційні підприємства;
- промислові споживачі.
Компанії потрібно:
- вести облік абонентів;
- зберігати договори;
- вести особові рахунки;
- фіксувати об’єкти підключення;
- вести лічильники;
- приймати показники;
- розраховувати споживання;
- виставляти рахунки;
- приймати оплати;
- контролювати борги;
- надсилати нагадування;
- формувати звіти для адміністрації.
Основний бізнес-процес
Типовий процес роботи енергетичної компанії виглядає так:
- оператор створює абонента;
- створює договір і особовий рахунок;
- додає об’єкт підключення;
- додає один або кілька лічильників;
- призначає тарифний план;
- абонент або оператор передає показники;
- система знаходить попередній показник;
- система розраховує споживання за період;
- система визначає чинний тариф;
- система формує нарахування;
- формується рахунок;
- рахунок надсилається абоненту;
- абонент оплачує повністю або частково;
- система оновлює статус рахунку;
- у разі несплати формується заборгованість;
- адміністрація формує звіти.
Основні об’єкти модуля
| Об’єкт | Призначення |
|---|---|
| Абоненти | Фізичні та юридичні особи, які споживають ресурси |
| Договори | Юридична основа надання послуг |
| Особові рахунки | Облікові рахунки абонентів |
| Об’єкти підключення | Адреси або об’єкти, де споживається ресурс |
| Типи ресурсів | Електроенергія, газ, вода, тепло |
| Тарифні плани | Ціни за одиницю ресурсу |
| Лічильники | Прилади обліку споживання |
| Показники | Дані лічильників за період |
| Нарахування | Розраховані суми до сплати |
| Рахунки | Документи для оплати |
| Оплати | Фактичні платежі |
| Борги | Несплачені суми |
| Переплати | Надлишкові платежі |
| Сповіщення | Нагадування про показники, рахунки та борги |
| Звіти | Аналітика по споживанню, оплатах і боргах |
Довідник «Абоненти»
Абонент — це клієнт енергетичної компанії.
Типи абонентів
- фізична особа;
- юридична особа;
- ФОП;
- ОСББ;
- бюджетна установа;
- промисловий споживач.
Поля абонента
| Поле | Опис |
|---|---|
| ПІБ або назва компанії | Найменування абонента |
| Тип абонента | Фізична особа, юридична особа, ОСББ тощо |
| Телефон | Контактний номер |
| Для рахунків і сповіщень | |
| Адреса | Основна адреса абонента |
| ІПН / ЄДРПОУ | Ідентифікаційний код, якщо потрібно |
| Договір № | Номер основного договору |
| Особовий рахунок | Унікальний рахунок абонента |
| Статус | Активний, призупинений, відключений, архівний |
| Коментар | Внутрішня примітка |
Довідник «Договори»
Договір визначає умови надання ресурсу абоненту.
Поля договору
| Поле | Опис |
|---|---|
| Номер договору | Унікальний номер |
| Абонент | З ким укладено договір |
| Тип ресурсу | Електроенергія, газ, вода, тепло |
| Дата початку | Початок дії договору |
| Дата завершення | Кінець дії, якщо є |
| Тарифний план | Базовий тариф |
| Об’єкт підключення | Адреса або об’єкт споживання |
| Статус | Активний, призупинений, завершений, розірваний |
| Файл договору | Скан або 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 |
Рекомендовані сутності бази даних
Для реалізації задачі доцільно передбачити такі сутності:
- абоненти;
- договори;
- особові рахунки;
- об’єкти підключення;
- типи ресурсів;
- тарифні плани;
- лічильники;
- показники лічильників;
- нарахування;
- рахунки;
- позиції рахунків;
- оплати;
- борги;
- переплати;
- сповіщення;
- документи;
- журнал змін;
- права доступу;
- звіти.
Практичне завдання
У межах атестації потрібно продемонструвати робочий сценарій.
Мінімальний сценарій:
- створити тип ресурсу;
- створити тарифний план;
- створити абонента;
- створити договір;
- створити особовий рахунок;
- створити об’єкт підключення;
- додати лічильник;
- внести попередній показник;
- внести поточний показник;
- перевірити автоматичний розрахунок споживання;
- сформувати рахунок;
- сформувати PDF-рахунок;
- зафіксувати часткову оплату;
- перевірити залишок боргу;
- зафіксувати повну оплату;
- перевірити зміну статусу рахунку на «Оплачено»;
- передати показник через кабінет абонента, якщо реалізовано;
- сформувати звіт споживання;
- сформувати звіт оплат;
- сформувати звіт боргів;
- перевірити журнал змін і права доступу.
Критерії оцінювання
| Критерій | Бали | Що перевіряється |
|---|---|---|
| Реалізація бази абонентів, лічильників і тарифів | 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-сповіщення |