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