Перейти до вмісту

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

Матеріал з K2 ERP Wiki
R (обговорення | внесок)
Бюрократи, Адміністратори інтерфейсу, Адміністратори
2367 редагувань
ВізуальнийВікірозмітка
Первинна публікація
 
Немає опису редагування
 
Рядок 1: Рядок 1:
== Реальний бізнес-контекст ==
{| class="wikitable" style="width:100%;"


== Основні задача ==
платформа повинна підтримувати часткову оплату. 100
Необхідно:


* постачає клієнтам:
! ! SEO-опис
** електроенергію;
** газ;
** воду;
* функціонує з абонентами:
** фізичними особами;
** юридичними особами;
* веде обліковий облік підключених абонентів;
* реєструє показники лічильників;
* формує рахунки за спожиті ресурси;
* приймає оплату і контролює заборгованість.=== 3. База «Показники лічильників» ===


* генерація рахунку;
== Приклади документів ==
* можливість роздруку;
{| class="wikitable" style="width:100%;"
* відправка рахунку через Email.==== Колонки бази ====
== базовий бізнес-процес ==
=== 4. Формування рахунків ===
{| class="wikitable"
=== 6. Додаткові функції ===
|-
|-
|Бекенд
| Бекенд
|K2 Cloud ERP на Python або PHP
| K2 Cloud ERP на Python або PHP
|-
|-
|БД
| База даних
|PostgreSQL або MySQL
| PostgreSQL або MySQL
|-
|-
|Фронтенд
| Фронтенд
|HTML5, JavaScript, AJAX, Fetch API або Axios
| HTML5, JavaScript
|-
|-
|UI-компоненти
| AJAX
|DataTables для таблиць абонентів, лічильників і рахунків; Select2 для пошуку по клієнтах і ресурсах
| Fetch API або Axios
|-
|-
|Друк
| UI-компоненти
|Генерація рахунків і актів у PDF
| DataTables для таблиць абонентів, лічильників, показників і рахунків; Select2 для пошуку абонентів, ресурсів і тарифів
|-
| Особистий кабінет
| Кабінет абонента для передачі показників і перегляду рахунків
|-
| Імпорт
| CSV-імпорт показників або оплат, опціонально
|-
| API
| Прийом показників або оплат через API, опціонально
|-
| Друк
| PDF-рахунки, акти звірки, квитанції, звіти
|-
| Експорт
| Excel або PDF для звітів
|-
| Сповіщення
| SMS або Email
|}
 
{| class="wikitable" style="width:100%;"
 
!== Документи ==
 
== AJAX-інтерактив ==
 
</pre>
 
# створити тип ресурсу;
# створити тарифний план;
# створити абонента;
# створити договір;
# створити особовий рахунок;
# створити об’єкт підключення;
# додати лічильник;
# внести попередній показник;
# внести поточний показник;
# перевірити автоматичний розрахунок споживання;
# сформувати рахунок;
# сформувати PDF-рахунок;
# зафіксувати часткову оплату;
# перевірити залишок боргу;
# зафіксувати повну оплату;
# перевірити зміну статусу рахунку на '''«Оплачено»''';
# передати показник через кабінет абонента, якщо реалізовано;
# сформувати звіт споживання;
# сформувати звіт оплат;
# сформувати звіт боргів;
# перевірити журнал змін і права доступу. | компонент обліку енергетичної або комунальної компанії
|-
| Які довідники потрібні? Рівень
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
{| class="wikitable" style="width:100%;"
|-
| Що потрібно створити?[[Категорія:K2 ERP]]
</div>
! Разом
 
! SEO-опис
 
! '''провідний принцип.''' Сума рахунку має формуватися не вручну, а на основі фактичного або нормативного споживання, чинного тарифу і правил нарахування. * квартира;
* приватний будинок;
* офіс;
* магазин;
* складський облік;
* виробничий цех;
* котельня;
* будівельний майданчик.== Поля лічильника ==
 
== Поля показника ==
== Поля абонента ==
== Особові рахунки ==
|-
| Абонент
| Власник або користувач системи об’єкта
|-
| Назва об’єкта
| як приклад: Квартира, складський облік №1, Офіс
|-
| Адреса підключення
| Фактична адреса
|-
| Тип об’єкта
| Житловий, комерційний, промисловий
|-
| Тип ресурсу
| Електроенергія, газ, вода, тепло
|-
| Потужність / ліміт
| Опціонально
|-
| Статус
| Підключено, призупинено, відключено, архів
|}
 
! Бали
 
== Критичні помилки ==
 
Енергетична або комунальна компанія-користувач постачає клієнтам ресурси:
 
== Приклади об’єктів ==
компонент має забезпечувати повний цикл роботи постачальника ресурсів: абонент → договір → об’єкт підключення → лічильник → показник → споживання → тариф → нарахування → рахунок → оплата → борг або переплата → звіт. У межах атестації потрібно продемонструвати робочий сценарій. !== Довідник «Договори» ==
 
!== Назва задача ==
 
* вести обліковий облік абонентів;
* зберігати договори;
* вести особові рахунки;
* фіксувати об’єкти підключення;
* вести лічильники;
* приймати показники;
* розраховувати споживання;
* виставляти рахунки;
* приймати оплати;
* контролювати борги;
* надсилати нагадування;
* формувати звіти для адміністрації.== Сповіщення ==
 
Рахунок формується на основі споживання і тарифу. * вести базу абонентів;
* вести договори;
* вести особові рахунки;
* вести об’єкти підключення;
* вести типи ресурсів;
* вести тарифні плани;
* вести лічильники;
* прив’язувати кілька лічильників до одного абонента;
* реєструвати показники лічильників;
* розраховувати споживання за період;
* автоматизовано формувати нарахування;
* формувати рахунки;
* фіксувати повну або часткову оплату;
* контролювати борги;
* контролювати переплати;
* підтримувати особистий кабінет абонента;
* приймати показники онлайн;
* надсилати SMS або Email-нагадування;
* формувати PDF-рахунки й акти;
* формувати звіти по споживанню, оплатах, боргах і тарифах. SEO-опис
 
! При частковій оплаті:
 
компонент має підтримувати абонентів, договори, особові рахунки, об’єкти підключення, типи ресурсів, тарифні плани, лічильники, показники, розрахунок споживання, нарахування, рахунки, оплати, борги, переплати, особистий кабінет абонента, SMS/Email-сповіщення, PDF-документи, звіти, AJAX-інтерактив, журнал змін і рольовий доступ. {| class="wikitable" style="width:100%;"
 
== Звіти ==
 
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
 
* абонента;
* об’єкт підключення;
* тип ресурсу;
* попередній показник;
* поточний показник;
* споживання;
* тариф;
* суму нарахування. Відповідь
|-
| Створено
| Рахунок сформовано
|-
| Надіслано
| Рахунок відправлено абоненту
|-
| Очікує оплату
| Оплати ще немає
|-
| Частково оплачено
| Оплачено не всю суму
|-
| Оплачено
| Рахунок на 100% закрито
|-
| Прострочено
| Термін оплати минув
|-
| Скасовано
| Рахунок скасовано
|}
|}


==== функції ERP ====
платформа має підтримувати SMS або Email-сповіщення. У звіті потрібно відображати:
Поля довідника:
 
автоматичний розрахунок виступає ключовою рисою * споживання за період. !Бали
Договір визначає умови надання ресурсу абоненту.== Звіт «Споживання за період» ==
=== 1. Структура довідників ===


==== Довідник «Типи ресурсів» ====
! Поле
! компонент має підтримувати рольову модель. SEO-опис


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


* номер рахунку;
* номер рахунку;
* період споживання;
* абонента;
* сума до сплати;
* період;
* статус:
* ресурс;
** створено;
* суму;
** оплачено;
* оплачено;
** прострочено. ERP для енергетичної компанії — критично важлива для:
* борг;
* статус. Поле
Тип ресурсу визначає одиницю виміру і правила обліку. | Кабінет абонента, онлайн-передачу показників, CSV/API-імпорт, SMS/Email-сповіщення
|}


==== Колонки бази ====
!== Оплати ==


<math> \text {Сума до сплати} = \text {Споживання} \times \text {Тариф} </math>
Через AJAX мають працювати:
==== Довідник «Абоненти» ====


* ПІБ або назва компанії;
Абонент повинен мати можливість працювати з власними даними. SEO-опис
* тип:
** фізична особа;
** юридична особа;
* адреса підключення;
* телефон;
* email;
* договір №;
* особовий рахунок.==== функції ERP ====


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


* лічильник;
! |-
* дата показника;
| Номер рахунку
* значення — поточні покази;
| Унікальний номер
=== 2. База «Лічильники» ===
|-
| Абонент
| Власник рахунку
|-
| Тип ресурсу
| Ресурс, за який ведеться обліковий облік
|-
| Об’єкт підключення
| Адреса споживання
|-
| Поточний баланс
| Борг або переплата
|-
| Статус
| Активний, заблокований, архівний
|}
 
Показник — це значення лічильника на певну дату. ! Один абонент здатна мати кілька об’єктів підключення.== Довідник «Типи ресурсів» ==
 
[[Категорія:Фінансовий облік]]
 
== Очікуваний результат ==
 
* хто створив абонента;
* хто змінив інформаційні дані абонента;
* хто створив договір;
* хто створив об’єкт підключення;
* хто додав лічильник;
* хто змінив статус лічильника;
* хто вніс показник;
* хто змінив або скасував показник;
* хто сформував рахунок;
* хто скасував рахунок;
* хто зафіксував оплату;
* хто змінив тариф;
* хто надіслав сповіщення;
* дату й час дії;
* старе та нове значення, якщо це можливо. У звіті потрібно відображати:
 
Мета задача — створити в K2 ERP компонент для автоматизації роботи енергетичної або комунальної компанії, яка надає послуги постачання ресурсів.== Часткова оплата ==
== Базова формула ==
Інтерфейс має працювати оперативно й без перезавантаження сторінок. Параметр
 
{| class="wikitable" style="width:100%;"
 
У результаті виконання атестаційного задача має бути створений компонент енергетичної компанії в K2 ERP. Компанії потрібно:
 
платформа здатна підтримувати складніші тарифи:
 
* сума оплати зменшує борг;
* рахунок отримує статус '''«Частково оплачено»''';
* залишок боргу залишається відкритим. |-
| Електроенергія
| кВт⋅год
|-
| Газ
| м³
|-
| Вода
| м³
|-
| Тепло
| Гкал
|-
| Гаряча вода
| м³
|}


==== інформаційні дані рахунку ====
У звіті потрібно відображати:


* внесення показників:
== Розрахунок споживання ==
** вручну;
** через імпорт CSV;
** через API;
* розрахунок спожитого обсягу за період:
** поточне значення мінус попереднє значення. Поля довідника:
==== Довідник «Тарифні плани» ====


* електроенергія;
! SEO-опис
* газ;
 
* вода;
== У кабінеті абонент бачить ==
* тепло. функції ERP:
 
Типи ресурсів:
== Довідник «Об’єкти підключення» ==
 
! {| class="wikitable" style="width:100%;"
 
== Статуси рахунку ==
 
== Практичне задача ==
компонент повинен фіксувати ключові дії. Поле
У звіті потрібно відображати:
 
! Енерго-компанія''' — це практична задача для перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні модуля обліку абонентів, договорів, об’єктів підключення, лічильників, тарифів, показників споживання, рахунків, оплат, заборгованості, сповіщень і звітності для енергетичної або комунальної компанії виступає ключовою рисою '''Атестаційне задача K2 ERP. Сума до сплати = Споживання × Тариф
== Події для сповіщень ==
|-
| Абонент
| Хто оплатив
|-
| Особовий рахунок
| На який рахунок зараховано
|-
| Рахунок
| Який рахунок закривається
|-
| Дата оплати
| Коли отримано оплату
|-
| Сума
| Розмір платежу
|-
| Спосіб оплати
| Готівка, картка, переказ тощо
|-
| Статус
| Очікує, успішно, помилка, повернення
|-
| Коментар
| Примітка оператора
|}
 
ERP для енергетичної або комунальної компанії критично важлива для точного обліку споживання, автоматизації рахунків, своєчасного отримання оплат і контролю заборгованості. * фізична особа;
* юридична особа;
* ФОП;
* ОСББ;
* бюджетна установа;
* промисловий споживач.[[Категорія:CRM]]
 
[[Категорія:Енерго-компанія]]
 
* нарахування за середнім споживанням;
* нарахування за нормативом;
* ручне нарахування оператором;
* блокування формування рахунку до внесення показників.== Поля особового рахунку ==
 
Типовий бізнес-процес роботи енергетичної компанії виглядає так:
== Довідник «Абоненти» ==
== Коротко ==
! Критерій
 
* [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[CRM]]
* [[Каса]]
* [[Рахунок на оплату]]
* [[Особистий кабінет]]
* [[Договір]]
* [[Білінг]]
* [[Лічильник]]
* [[Тариф]]
* [[AJAX]]
 
[[Категорія:Комунальні послуги]]
== Поля рахунку ==
! {| class="wikitable" style="width:100%;"
 
'''Умова складання.''' задача не здатна бути зараховане, якщо платформа не дає можливість пройти базовий цикл енергетичної компанії: абонент → лічильник → показник → споживання → тариф → рахунок → оплата → борг або переплата → звіт. * абонента;
* особовий рахунок;
* ресурс;
* суму боргу;
* кількість прострочених рахунків;
* дату останньої оплати. Ресурс
 
* попередній показник: 1200 кВт⋅год;
* поточний показник: 1350 кВт⋅год;
* споживання: 150 кВт⋅год;
* тариф: 4 грн за кВт⋅год;
* сума до сплати: 600 грн. Значення
== Основні об’єкти модуля ==
|-
| Абоненти
| Фізичні та юридичні особи, які споживають ресурси
|-
| Договори
| Юридична основа надання послуг
|-
| Особові рахунки
| Облікові рахунки абонентів
|-
| Об’єкти підключення
| Адреси або об’єкти, де споживається ресурс
|-
| Типи ресурсів
| Електроенергія, газ, вода, тепло
|-
| Тарифні плани
| Ціни за одиницю ресурсу
|-
| Лічильники
| Прилади обліку споживання
|-
| Показники
| інформаційні дані лічильників за період
|-
| Нарахування
| Розраховані суми до сплати
|-
| Рахунки
| Документи для оплати
|-
| Оплати
| Фактичні платежі
|-
| Борги
| Несплачені суми
|-
| Переплати
| Надлишкові платежі
|-
| Сповіщення
| Нагадування про показники, рахунки та борги
|-
| Звіти
| аналітичні інструменти по споживанню, оплатах і боргах
|}
 
Для реалізації задачі доцільно передбачити такі сутності:
 
! | PDF-рахунки, квитанції, акти звірки, повідомлення про борг
|-
| Які звіти потрібні?== Типи ресурсів ==
 
== Довідник «Тарифні плани» ==
 
# оператор створює абонента;
# створює договір і особовий рахунок;
# додає об’єкт підключення;
# додає один або кілька лічильників;
# призначає тарифний план;
# абонент або оператор передає показники;
# платформа знаходить попередній показник;
# платформа розраховує споживання за період;
# платформа визначає чинний тариф;
# платформа формує нарахування;
# формується рахунок;
# рахунок надсилається абоненту;
# абонент оплачує на 100% або частково;
# платформа оновлює статус рахунку;
# у разі несплати формується заборгованість;
# адміністрація формує звіти.<pre>
|-
| Абонент
| Власник або користувач системи
|-
| Об’єкт підключення
| Де встановлений лічильник
|-
| Тип ресурсу
| Що обліковує
|-
| Номер лічильника
| Серійний номер
|-
| Модель
| Опціонально
|-
| Дата встановлення
| Коли встановлено
|-
| Дата повірки
| Дата останньої повірки
|-
| Дата наступної повірки
| Коли потрібно перевірити
|-
| Початковий показник
| Показник при встановленні
|-
| Місце встановлення
| Квартира, щитова, підвал тощо
|-
| Статус
| Активний, демонтований, на повірці, несправний
|}
 
! Об’єкт
 
== Примітка ==
! | Споживання, рахунки, оплати, борги, лічильники на повірку, доходи по ресурсах
|-
| Що виступає як критичною вимогою? Призначення
 
{| class="wikitable" style="width:100%;"
 
== Мета задача ==
 
!{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Енерго-компанія}}
 
== Звіт «Доходи по ресурсах» ==
 
== Нарахування без показників, опціонально ==
Журнал змін має зберігати:
Лічильник — це прилад обліку споживання ресурсу. Статус
У звіті потрібно відображати:
|-
| ПІБ або назва компанії
| Найменування абонента
|-
| Тип абонента
| Фізична особа, юридична особа, ОСББ тощо
|-
| Телефон
| Контактний номер
|-
| Email
| Для рахунків і сповіщень
|-
| Адреса
| Основна адреса абонента
|-
| ІПН / ЄДРПОУ
| Ідентифікаційний код, якщо потрібно
|-
| Договір №
| Номер основного договору
|-
| Особовий рахунок
| Унікальний рахунок абонента
|-
| Статус
| Активний, призупинений, відключений, архівний
|-
| Коментар
| Внутрішня примітка
|}
 
{| class="wikitable" style="width:100%;"
 
! * тип ресурсу;
* обсяг споживання;
* суму нарахувань;
* суму оплат;
* борг;
* частку ресурсу в доході. Поле
 
* залишити на балансі абонента;
* врахувати в наступному рахунку;
* повернути вручну, якщо реалізовано. !== Звіт «Оплати за період» ==


* назва тарифу;
* абонента;
* об’єкт;
* номер лічильника;
* тип ресурсу;
* тип ресурсу;
* ціна за одиницю виміру:
* дату наступної повірки;
** кВт⋅год;
* статус. Одиниця виміру
** м³;
 
** Гкал;
'''компонент обліку абонентів, обсягів споживання енергії, рахунків і платежів для енергетичної компанії'''. | Абоненти, ресурси, тарифи, лічильники, об’єкти підключення
* період дії тарифу:
|-
** дата початку;
| Який провідний бізнес-процес? ! Бали
** дата завершення. !Критерій
|-
| Реалізація бази абонентів, лічильників і тарифів
| 20
| Абоненти, договори, особові рахунки, об’єкти підключення, ресурси, тарифи, лічильники
|-
| обліковий облік споживання і формування рахунків
| 20
| Показники, попередні і поточні значення, споживання, тариф, нарахування, рахунок
|-
| Фінансовий обліковий облік оплат і заборгованості
| 20
| Часткові оплати, повні оплати, борги, переплати, статуси рахунків, акти звірки
|-
| Генерація документів і інтеграційні функції ERP нагадувань
| 20
| PDF-рахунки, квитанції, акти, SMS/Email-нагадування, кабінет абонента
|-
| Інтерактивність через AJAX і мобільна адаптивність
| 20
| AJAX-пошук, внесення показників, розрахунок рахунків, оплати, фільтри, кабінет абонента
|-
{| class="wikitable" style="width:100%;"
У звіті потрібно відображати:
== Логування змін ==
|}
 
</pre>
 
! Тарифний план визначає ціну одиниці ресурсу за певний період. SEO-опис
== Звіт «Борги абонентів» ==
|-
| Лічильник
| До якого лічильника належить показник
|-
| Абонент
| Власник лічильника
|-
| Дата показника
| Коли передано або внесено показник
|-
| Період
| Місяць або інший обліковий період
|-
| Значення
| Поточний показник
|-
| Попереднє значення
| автоматизовано з попереднього періоду
|-
| Споживання
| Різниця між поточним і попереднім значенням
|-
| Джерело
| Вручну, кабінет абонента, CSV, API
|-
| Статус
| Новий, перевірено, помилковий, скасований
|}
 
[[Категорія:Корпоративна Wiki]]
 
[[Категорія:Атестаційні завдання K2]]
 
Якщо абонент сплатив більше, ніж сума рахунку, платформа має зафіксувати переплату. __TOC__
 
== Варіанти тарифікації, опціонально ==
 
* готівка;
* банківська картка;
* банківський переказ;
* онлайн-оплата;
* платіжний термінал;
* імпорт банківської виписки;
* ручне внесення оператором.== Переплата ==
 
* фізичні особи;
* юридичні особи;
* ОСББ;
* бюджетні установи;
* комерційні підприємства;
* промислові споживачі. {| class="wikitable" style="width:100%;"
Базова формула:
! ! Поле
{| class="wikitable" style="width:100%;"
Споживання = Поточний показник - Попередній показник
платформа має формувати PDF-документи. Максимальна оцінка
 
Якщо поточний показник менший за попередній, платформа має показати попередження. | Показники, споживання, тарифи, рахунки, борги, переплати, повірки лічильників
|-
| Які документи потрібні? ! Поле
компанія-користувач функціонує з різними категоріями абонентів:
|-
| Номер договору
| Унікальний номер
|-
| Абонент
| З ким укладено договір
|-
| Тип ресурсу
| Електроенергія, газ, вода, тепло
|-
| Дата початку
| Початок дії договору
|-
| Дата завершення
| Кінець дії, якщо виступає як
|-
| Тарифний план
| Базовий тариф
|-
| Об’єкт підключення
| Адреса або об’єкт споживання
|-
| Статус
| Активний, призупинений, завершений, розірваний
|-
| Файл договору
| Скан або PDF договору
|}
 
платформа має підтримувати фіксацію платежів. Поле
 
== Поля об’єкта підключення ==


* прив’язка кількох лічильників до одного абонента. {| class="wikitable"
<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">


* робота через AJAX для миттєвого оновлення версій показників і рахунків;
* рахунок на оплату;
* особистий кабінет абонента:
* акт звірки;
** перегляд історії споживання;
* квитанція про оплату;
** оплата рахунків;
* повідомлення про борг;
** передача показників онлайн;
* історія продукту споживання;
* SMS / Email-сповіщення:
* звіт по особовому рахунку;
** нагадування про необхідність передачі показників;
* акт встановлення лічильника, опціонально;
** нагадування про оплату рахунку;
* акт демонтажу лічильника, опціонально. SEO-опис
* генерація:
** щомісячних звітів про споживання;
** фінансових звітів для адміністрації.==== функції ERP ====


== Критерії оцінки ==
! Роль


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


* вести базу абонентів і облікових записів;
Абонент — це клієнт ERP енергетичної компанії. функції ERP
* реєструвати споживання за період;
== Поля тарифного плану ==
* формувати рахунки автоматизовано на основі споживання;
* відслідковувати стан оплат і надсилати нагадування. * фіксація оплати рахунків:
** готівка;
** безготівковий переказ;
** онлайн-оплата через API — опціонально;
* автоматичне оновлення версій статусу рахунку після оплати;
* технічна підтримка часткової оплати. * своєчасного отримання оплат. !Параметр
|-
|-
|Реалізація бази абонентів, лічильників і тарифів
| Назва тарифу
|20
| як приклад: Населення, бізнес-середовище, Промисловий
|-
|-
|обліковий облік споживання і формування рахунків
| Тип ресурсу
|20
| Електроенергія, газ, вода, тепло
|-
|-
|Фінансовий обліковий облік оплат і заборгованості
| Категорія абонента
|20
| Фізична особа, юридична особа, промисловий споживач
|-
|-
|Генерація документів і інтеграційні функції ERP нагадувань
| Одиниця виміру
|20
| кВт⋅год, м³, Гкал
|-
|-
|Інтерактивність через AJAX і мобільна адаптивність
| Ціна за одиницю
|20
| Вартість одиниці ресурсу
|-
| Дата початку дії
| З якої дати тариф чинний
|-
| Дата завершення дії
| До якої дати тариф чинний
|-
| Статус
| Активний, архівний
|}
|}


=== 5. Оплата ===
== Критерії оцінювання ==
= компонент обліку абонентів, обсягів споживання енергії, рахунків і платежів для енергетичної компанії =
 
== Способи оплати ==


* обліку споживання;
* фіксований тариф;
* автоматизації виставлення рахунків;
* денний / нічний тариф;
  == Примітка ==
* зонний тариф;
* соціальна норма;
* тариф за обсягами споживання;
* індивідуальний тариф для юридичних осіб. ! | Передача показників, розрахунок споживання, рахунок і оплата
|-
| Що потрібно контролювати? | Рахунок має формуватися на основі споживання і чинного тарифу
|-
| Що бажано додати? Поле
! SEO-опис
</div>
|-
| Номер рахунку
| Унікальний номер
|-
| Абонент
| Кому виставлено рахунок
|-
| Особовий рахунок
| Фінансовий рахунок абонента
|-
| Об’єкт підключення
| За який об’єкт рахунок
|-
| Тип ресурсу
| Електроенергія, газ, вода, тепло
|-
| Період споживання
| За який період сформовано
|-
| Споживання
| Обсяг за період
|-
| Тариф
| Ціна за одиницю
|-
| Сума
| Сума до оплати
|-
| Оплачено
| Скільки вже оплачено
|-
| Борг
| Залишок до оплати
|-
| Статус
| Створено, частково оплачено, оплачено, прострочено, скасовано
|}
 
[[Категорія:Білінг]]
 
<pre>
платформа повинна дозволяти:
! автоматизація процесів зменшує кількість ручних помилок, спрощує роботу операторів і покращує обслуговування абонентів. Питання
 
== Див. так само ==
 
== База «Показники лічильників» ==
! SEO-опис
!== Поля договору ==
== Технічні вимоги ==
{| class="wikitable" style="width:100%;"
 
== Реальний бізнес-контекст ==
 
== Типи абонентів ==
 
'''Коротко.''' Потрібно реалізувати компонент енергетичної компанії: абоненти, договори, об’єкти підключення, лічильники, ресурси, тарифи, показники, розрахунок споживання, рахунки, оплати, борги, особистий кабінет абонента, сповіщення, документи, звіти й AJAX-інтерактив.== Формування рахунків ==
 
Мінімальний сценарій:
 
Переплату можна:
 
* свої об’єкти підключення;
* свої лічильники;
* історію показників;
* історію споживання;
* рахунки;
* оплати;
* борг або переплату;
* можливість передати показники;
* можливість завантажити PDF-рахунок;
* повідомлення і нагадування. |-
| 90–100
| Відмінно
| компонент на 100% функціонує: абоненти, договори, особові рахунки, лічильники, показники, тарифи, рахунки, оплати, борги, кабінет абонента і звіти реалізовані коректно
|-
| 75–89
| Добре
| Основна логіка функціонує, виступає як незначні недоліки, які не руйнують бізнес-процес обліку споживання і оплат
|-
| 60–74
| Зараховано
| Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання
|-
| 0–59
| Не зараховано
| Відсутня критична логіка: абоненти, лічильники, показники, рахунки, оплати або борги
|}
 
== Рекомендовані сутності бази даних ==
 
== Шкала оцінювання ==
 
* неможливо створити абонента;
* неможливо створити особовий рахунок;
* неможливо створити лічильник;
* лічильник не прив’язується до абонента;
* неможливо внести показник;
* споживання не розраховується;
* рахунок не формується;
* рахунок не прив’язується до абонента;
* рахунок не враховує тариф;
* часткова оплата не змінює борг;
* повна оплата не змінює статус рахунку;
* переплата не фіксується;
* абонент у кабінеті бачить чужі рахунки або показники;
* звіти не відповідають фактичним показникам, рахункам і оплатам;
* зміни показників, рахунків, оплат і тарифів не логуються. Що перевіряється
 
Критичними помилками вважаються ситуації, коли:
 
== Звіт «Лічильники на повірку» ==
 
Якщо показники не передані, платформа здатна підтримувати:
 
! Особовий рахунок застосовують, коли потрібно для фінансового обліку абонента. ! * дату оплати;
* абонента;
* рахунок;
* суму;
* спосіб оплати;
* статус платежу.== Звіт «Рахунки за період» ==
== Поля оплати ==
== Особистий кабінет абонента ==
 
== Приклад ==
 
{| class="wikitable" style="width:100%;"
 
* електроенергію;
* газ;
* воду;
* тепло;
* гарячу воду;
* інші комунальні ресурси. Поле
  == База «Лічильники» ==

Поточна версія на 20:55, 1 травня 2026

платформа повинна підтримувати часткову оплату. 100
! SEO-опис

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Звіти

  • абонента;
  • об’єкт підключення;
  • тип ресурсу;
  • попередній показник;
  • поточний показник;
  • споживання;
  • тариф;
  • суму нарахування. Відповідь
Створено Рахунок сформовано
Надіслано Рахунок відправлено абоненту
Очікує оплату Оплати ще немає
Частково оплачено Оплачено не всю суму
Оплачено Рахунок на 100% закрито
Прострочено Термін оплати минув
Скасовано Рахунок скасовано

платформа має підтримувати SMS або Email-сповіщення. У звіті потрібно відображати:

Договір визначає умови надання ресурсу абоненту.== Звіт «Споживання за період» ==

Поле компонент має підтримувати рольову модель. SEO-опис

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

  • пошук абонентів;
  • створення абонента;
  • пошук особового рахунку;
  • додавання лічильника;
  • внесення показників;
  • розрахунок споживання;
  • формування рахунку;
  • фіксація оплати;
  • оновлення версій статусу рахунку;
  • фільтрація боргів;
  • фільтрація рахунків;
  • фільтрація показників;
  • формування звітів;
  • оновлення версій кабінету абонента. {| class="wikitable" style="width:100%;"
  • номер рахунку;
  • абонента;
  • період;
  • ресурс;
  • суму;
  • оплачено;
  • борг;
  • статус. Поле
Тип ресурсу визначає одиницю виміру і правила обліку. | Кабінет абонента, онлайн-передачу показників, CSV/API-імпорт, SMS/Email-сповіщення
== Оплати ==

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

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

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

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

Показник — це значення лічильника на певну дату. ! Один абонент здатна мати кілька об’єктів підключення.== Довідник «Типи ресурсів» ==

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

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

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

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

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

У результаті виконання атестаційного задача має бути створений компонент енергетичної компанії в K2 ERP. Компанії потрібно: платформа здатна підтримувати складніші тарифи:
  • сума оплати зменшує борг;
  • рахунок отримує статус «Частково оплачено»;
  • залишок боргу залишається відкритим. |-
Електроенергія кВт⋅год
Газ м³
Вода м³
Тепло Гкал
Гаряча вода м³

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

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

! SEO-опис

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

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

! {| class="wikitable" style="width:100%;"

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

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

компонент повинен фіксувати ключові дії. Поле У звіті потрібно відображати:

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

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

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

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

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

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

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

Коротко

! Критерій

Поля рахунку

! {| class="wikitable" style="width:100%;"

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

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

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

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

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

! | PDF-рахунки, квитанції, акти звірки, повідомлення про борг |- | Які звіти потрібні?== Типи ресурсів ==

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

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

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

! Об’єкт

== Примітка ==
! | Споживання, рахунки, оплати, борги, лічильники на повірку, доходи по ресурсах
|-
| Що виступає як критичною вимогою? Призначення

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

== Мета задача ==

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

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

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

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

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

* залишити на балансі абонента;
* врахувати в наступному рахунку;
* повернути вручну, якщо реалізовано. !== Звіт «Оплати за період» ==

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

'''компонент обліку абонентів, обсягів споживання енергії, рахунків і платежів для енергетичної компанії'''. | Абоненти, ресурси, тарифи, лічильники, об’єкти підключення
|-
| Який провідний бізнес-процес? ! Бали
|-
| Реалізація бази абонентів, лічильників і тарифів
| 20
| Абоненти, договори, особові рахунки, об’єкти підключення, ресурси, тарифи, лічильники
|-
| обліковий облік споживання і формування рахунків
| 20
| Показники, попередні і поточні значення, споживання, тариф, нарахування, рахунок
|-
| Фінансовий обліковий облік оплат і заборгованості
| 20
| Часткові оплати, повні оплати, борги, переплати, статуси рахунків, акти звірки
|-
| Генерація документів і інтеграційні функції ERP нагадувань
| 20
| PDF-рахунки, квитанції, акти, SMS/Email-нагадування, кабінет абонента
|-
| Інтерактивність через AJAX і мобільна адаптивність
| 20
| AJAX-пошук, внесення показників, розрахунок рахунків, оплати, фільтри, кабінет абонента
|-
{| class="wikitable" style="width:100%;"
У звіті потрібно відображати:
== Логування змін ==
|}



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



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


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


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


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


  • готівка;
    • 

  • банківська картка;
    • 

  • банківський переказ;
    • 

  • онлайн-оплата;
    • 

  • платіжний термінал;
    • 

  • імпорт банківської виписки;
    • 

  • ручне внесення оператором.== Переплата ==


  • фізичні особи;
    • 

  • юридичні особи;
    • 

  • ОСББ;
    • 

  • бюджетні установи;
    • 

  • комерційні підприємства;
    • 

  • промислові споживачі. {| class="wikitable" style="width:100%;"


Базова формула:
! ! Поле



Споживання = Поточний показник - Попередній показник
платформа має формувати PDF-документи. Максимальна оцінка

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



Які документи потрібні? ! Поле

компанія-користувач функціонує з різними категоріями абонентів:






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

Унікальний номер




Абонент

З ким укладено договір




Тип ресурсу

Електроенергія, газ, вода, тепло




Дата початку

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




Дата завершення

Кінець дії, якщо виступає як




Тарифний план

Базовий тариф




Об’єкт підключення

Адреса або об’єкт споживання




Статус

Активний, призупинений, завершений, розірваний




Файл договору

Скан або PDF договору



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



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




  • рахунок на оплату;
    • 

  • акт звірки;
    • 

  • квитанція про оплату;
    • 

  • повідомлення про борг;
    • 

  • історія продукту споживання;
    • 

  • звіт по особовому рахунку;
    • 

  • акт встановлення лічильника, опціонально;
    • 

  • акт демонтажу лічильника, опціонально. SEO-опис


! Роль



  • абоненти;
    • 

  • договори;
    • 

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

  • об’єкти підключення;
    • 

  • типи ресурсів;
    • 

  • тарифні плани;
    • 

  • лічильники;
    • 

  • показники лічильників;
    • 

  • нарахування;
    • 

  • рахунки;
    • 

  • позиції рахунків;
    • 

  • оплати;
    • 

  • борги;
    • 

  • переплати;
    • 

  • сповіщення;
    • 

  • документи;
    • 

  • журнал змін;
    • 

  • права доступу;
    • 

  • звіти. SEO-опис


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



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


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



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


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


  • фіксований тариф;
    • 

  • денний / нічний тариф;
    • 

  • зонний тариф;
    • 

  • соціальна норма;
    • 

  • тариф за обсягами споживання;
    • 

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


|-
| Що потрібно контролювати? | Рахунок має формуватися на основі споживання і чинного тарифу
|-
| Що бажано додати? Поле
! SEO-опис





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



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


Див. так само


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

! SEO-опис
!== Поля договору ==

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


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

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

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

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







90–100

Відмінно

компонент на 100% функціонує: абоненти, договори, особові рахунки, лічильники, показники, тарифи, рахунки, оплати, борги, кабінет абонента і звіти реалізовані коректно




75–89

Добре

Основна логіка функціонує, виступає як незначні недоліки, які не руйнують бізнес-процес обліку споживання і оплат




60–74

Зараховано

Базовий сценарій функціонує, але частина функцій реалізована неповно або потребує доопрацювання




0–59

Не зараховано

Відсутня критична логіка: абоненти, лічильники, показники, рахунки, оплати або борги




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


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

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

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


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

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

! Особовий рахунок застосовують, коли потрібно для фінансового обліку абонента. ! * дату оплати;
* абонента;
* рахунок;
* суму;
* спосіб оплати;
* статус платежу.== Звіт «Рахунки за період» ==

Поля оплати


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


Приклад



* електроенергію;
* газ;
* воду;
* тепло;
* гарячу воду;
* інші комунальні ресурси. Поле
 == База «Лічильники» ==





Отримано з https://wiki.kyiv.ua/index.php?title=Атестаційні_завдання_K2_ERP/Енерго-компанія&oldid=568