Технічне завдання на закупівлю послуг ^[1] щодо розробки, адміністрування та супроводу програмного комплексу з нарахування житлово-комунальних платежів м. Запоріжжя.

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

Архітектура ПЗ повинна бути побудована за сучасною трирівневої схемою: “клієнт – сервер додатків – сервер СKБД”, що зменшує функціональне навантаження на клієнта і на сервер бази даних і дає значних переваг перед використанням традиційної “клієнт – серверної” архітектури.

Бізнес-логіка з проведення нарахувань та перерахунків споживачів послуг ПЗ системи повинна бути відокремлена від СKБД в окремий модуль для зручності її подальшої модифікації при зміні алгоритмів розрахунку в слідстві зміни законодавства, а так само для роботи на окремому сервері в разі потреби збільшення продуктивності системи, а так само мати можливість змінити СKБД без зміни наявного коду бізнес логіки.

Можливість організації розподіленої Бази Даних (у кожного комунального підприємство окрема БД), що має на увазі організацію “синхронізацій” інформації між ними. З чітким розподілом відповідальності за загальні довідники.

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

Тривалість як перерахунку послуг за період позовної давності, так і по проведенню нарахувань для 1 000 000 споживачів послуг за підсумками закриття місяця не повинна перевищувати 3-х годин на 2-х процесорному сервері. Клієнтське ПЗ системи має забезпечувати виконання основної частини сервісних функцій для користувачів за допомогою використання обчислювальної потужності як самого комп’ютера клієнта з метою розвантаження центрального сервера, так і реалізація клієнтського робочого місця у вигляді “браузера” і перенесення сервісних функцій користувачів на центральний сервер.

Автоматизація всіх видів перерахунків, як за поточний, так і за минулі періоди в межах строку позовної давності, а в разі модифікації показань приладів обліку в межах даного терміну з відображенням підсумків перерахунку в бухгалтерських документах поточного звітного періоду, а підсумків перерахунку фізичного споживання ресурсу за періодами його реального споживання (Бізнес-логіка перерахунків підтримує два рівня обліку, бухгалтерський і збутовий, зі своєю історією).

Створення і використання електронних архівів сканованих копій первинних документів для забезпечення оперативної роботи з архівами первинних документів.

Автоматичне формування договорів з споживачами послуг засобами ПЗ на підставі даних, що зберігаються в системі.

Кількість робочих місць ПЗ системи не обмежується налаштуваннями системи. Оновлення клієнтської частини ПЗ виконується автоматично при оновленні серверної частини.

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

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

ПЗ повинно обов’язково вести історію змін всіх основних даних по споживачеві (в тому числі і сторнованих), підтримувати історичність бухгалтерської звітності та алгоритмів розрахунку.

Основні характерні параметри та характеристики (тарифи, ставки ПДВ тощо) повинні зберігатися в єдиній частині довідника.

Дотримання дворівневого контролю:

а) контроль дій оператора;

б) контроль (автоматичне розвантаження помилок) при закритті руху, закриття нарахувань та проведенні оплат;

в) контроль на виключення отримання від’ємного тарифу.

Права власності на ПЗ (без права перепродажів), БД та права адміністрування повинні належати “Замовнику”.

Зручна форма інтерфейсу з кольорами пастельних тонів, не втомлювати в процесі роботи очі.

Мінімальна комбінація набору символів при проведенні операцій в ПК.

Всі розрахунки в ПЗ повинні здійснюватись відповідно до норм і вимог:

   а) чинного Законодавства України;

   б) рішеннями органів місцевого самоврядування.

Взаємодія в автоматизованому режимі (експорт / імпорт даних) з іншими комплексами і системами (такими як ПК “Віртуоз”, АС “Банк-клієнт”).

2. Вимоги до функціональних можливостей ПЗ.

2.1. Система повинна забезпечувати зберігання такої інформації:

адресна інформація про споживачів;

адресна інформація про довірених осіб споживачів;

інформація про оплату споживачів;

інформація про тарифи;

інформація про надані споживачеві субсидії;

інформація про надання споживачеві пільг;

інформація про тип підключення споживача;

інформація про встановлене у споживача обладнання та об’єкти обліку;

інформація про прилади обліку та їхні показання;

інформація про номерні пломбах (установка, зняття);

інформація про укладення (переукладання) договорів;

інформація про графік реструктуризації заборгованості;

інформація про заборгованість споживачів;

інформація по сформованих рахунках на оплату;

інформація по сформованих та доставлених попередженнях (претензіях) про борг з наступним відключенням;

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

перелік надаваних послуг;

інформація про рішення суду про стягнення заборгованості (рішення суду, після набрання чинності, по споживачеві має відображатись та перебувати у програмі);

2.2. Виконання нарахувань за всі типи житлово-комунальних послуг в одній системі.

2.2.1. Всі автоматичні розрахунки, вироблені ПЗ повинні відповідати чинному Законодавству України.

2.2.2. Розрахунок щомісячних нарахувань:

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

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

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

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

розрахунок нарахування, виходячи з даних про субсидії, як встановленої, так і з урахуванням перерахунку;

розрахунок нарахувань повинно проводитися відповідно до діючих на момент розрахунку тарифам (у тому числі, якщо розрахунки проведені за попередні періоди);

можливість перерахунку за попередні періоди.

2.2.3. Розрахунок відповідних типів сальдо по кожній послузі:

розрахунок бухгалтерського щомісячного сальдо по споживачам (включаючи і за рішеннями суду);

розрахунок фактичного щомісячного сальдо по споживачам (оплати закривають спочатку поточні нарахування і тільки потім нарахування минулих періодів).

2.3. Електронний обмін даними з банками, які беруть оплати за спожиту послугу від споживачів. Вирішення цього завдання має обумовлювати:

– Імпорт електронного реєстру оплат;

– Перевірку імпортованого електронного реєстру оплат на коректність;

– Внесення оплат до системи;

– Робота з “помилковими” оплатами.

Аналогічним способом забезпечити роботу з наданими даними від відділів субсидій.

2.4. У системі повинен бути реалізований модуль “Субсидія” (запити як по одному споживачеві, так і пакетний за переліком споживачів з автоматичним заповненням фактичними нарахуваннями) – online доступ в районних відділах УПСЗН.

2.5. Використання планшетів:

У системі повинна бути можливість виконання контрольних обходів з використанням електронних планшетів.

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

При використанні планшету повинна бути можливість фото-фіксації показань приладу обліку, фото-фіксації стану пломб і корпусу приладу обліку.

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

Можливість автоматичної фіксації GPS координат об’єкта контролю.

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

автоматичне формування рахунків, попереджень і нарядів на відключення;

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

2.7. Система електронної черги.

Вбудована в систему електронна черга повинна забезпечити перелік наступних можливостей:

Ведення оперативної черги

Ведення черги попереднього запису на інші дні

Запис у попередню чергу через інтернет

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

Адресна запис споживачів в чергу з наданням інформації про суму боргу

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

Управління викликом особових рахунків для операторів

Управління викликом споживачів

Контроль причин звернення споживачів

Контроль врегульованих питань

Контроль часу очікування прийому

Контроль тривалості обслуговування

2.8. Отримання не менше 80 звітних форм

Отримання 80 звітних форм, у тому числі всіх основних форм УПСЗН.

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

2.9. Електронні архіви первинних документів.

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

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

– Можливість створення архівів багатосторінкових документів як єдиного документа.

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

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

2.10. Самообслуговування споживачів через Інтернет має забезпечувати:

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

Можливість за запитом споживача, системою автоматично, надати докладну розшифровку нарахувань вартості послуг (спожитої кількості ресурсу або послуги).

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

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

2.11. Самообслуговування споживачів через СМС.

Можливість передачі показань приладу обліку.

Можливість отримання наступної інформації за запитом споживача:

Значення сальдо.

Інформація про наявність та типі пільги.

Інформації про останні платежі, що надійшли.

Інформація про застосовувані тарифах.

Час відповіді не повинен перевищувати 60 секунд.

2.12. Можливість формування “єдиного рахунку” для всіх типів житлово-комунальних послуг за принципом роботи “ОСББ”.

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