4.Требования к выполнению работ
4.1 Требования к системе в целом
По виду автоматизированной деятельности Система должна представлять собой многопользовательскую территориально распределенную информационно-телекоммуникационную систему обработки и передачи информации с различным уровнем доступа пользователей к обрабатываемой информации, не составляющей государственной тайны – служебной информации ограниченного доступа, получаемой в рамках выполнения участниками своих функций.
Система должна быть предоставлена в виде прикладных функциональных сервисов, располагающихся на аппаратно-программной платформе Исполнителя и предоставляемых по модели «программное обеспечение как услуга» (SaaS).
Сервисы должны представлять собой высокоуровневые компоненты Системы, обладающие свойством автономности, выделенные по признакам принадлежности к определенной группе участников процесса ЖКХ или предназначенные для решения специфических задач. Информационное взаимодействие между сервисами должно осуществляться с использованием комплексной среды передачи данных.
Система должна иметь централизованную базу данных, которая позволит:
исключить необходимость экспорта-импорта данных (все действия происходят непосредственно с единой базой данных);
получить возможность постоянного (online) доступа к системе и всей текущей информации (без привязки к стационарному рабочему месту пользователя);
вести единые справочники и классификаторы (централизованный контроль наполнения справочников).
Система должна быть организована и работать по принципу трехзвенной архитектуры: web-клиент, web-сервер приложений и сервер базы данных.
Доступ пользователей к функциональным сервисам должен осуществляться по технологии «тонкого клиента» на базе web-обозревателя (браузера) посредством АРМ. Тип используемого АРМ и состав функций, доступный определенному пользователю, должен определяться в зависимости от его роли, при этом роль будет определять права пользователей на доступ к сервисам, функциям и данным, а АРМ – способ представления информации и размещения управляющих элементов, оптимизированные для соответствующей категории пользователей.
Система должна обеспечивать возможность исторического хранения данных с глубиной не менее 30 лет.
Перечень подсистем, их назначение и основные характеристики
В Системе должны присутствовать следующие подсистемы:
Подсистема администрирования
Подсистема единых справочников и классификаторов;
Подсистема единых реестров;
Подсистема субсидирования;
Подсистема учета программ и объектов капитального ремонта;
Подсистема начислений абонентам;
Подсистема финансового учета;
Подсистема исполнения программ;
Подсистема контроля над формированием фондов;
Подсистема аналитики и отчетности;
Подсистема взаимодействия с внешними информационными системами.
4.2.1 Требования к Подсистеме администрирования
В Подсистеме администрирования должна быть организована работа следующих АРМ пользователей:
– АРМ администратора;
– АРМ главного бухгалтера регионального оператора.
Подсистема администрирования должна позволять осуществлять следующие функции в соответствии с АРМ пользователя:
№
|
Функция
|
АРМ администратора
|
АРМ главного бухгалтера
|
1.
|
Возможность предоставления информации на основе журналов
|
Х
|
|
2.
|
Возможность ограничения доступа к информации и функциям Системы на основе ролевой модели
|
Х
|
|
3.
|
Возможность гибкой настройки правил и порядка согласования объектов Системы указанных в настоящем Техническом задании на основе статусной модели
|
Х
|
|
4.
|
Возможность проведения служебных операций
|
Х
|
Х
|
1) Возможность предоставления информации на основе журнала действий пользователей.
2) Возможность ограничения доступа к информации и функциям Системы на основе ролевой модели. В Подсистеме должна быть обеспечена возможность:
создания неограниченного количества пользователей.
гибкой настройки ограничений для пользователей на основе ролевой модели.
Подробные требования к ролевой модели представлены в п. 4.1.7 Требования к доступу пользователей к Системе.
3) Возможность гибкой настройки правил и порядка согласования объектов Системы указанных в настоящем Техническом задании на основе статусной модели. В Подсистеме должна быть обеспечена возможность:
создания состояний (статусов) объектов Системы, переходов между состояниями и правил переходов. Правило перехода, это заведомо известный алгоритм действий, выполняемый при переходе с одного определенного состояния на другое.
гибкой настройки ограничений доступа к информации и функциям в зависимости от состояния (статуса) объектов.
4) Возможность проведения служебных операций. В Подсистеме должна быть обеспечена возможность проведения следующих служебных операций:
Индексации. В рамках операции индексации должна быть возможность изменения размера:
процентной ставки по займу на оплату услуг и работ по капитальному ремонту МКД. Начисление процентов по займу происходит ежегодно 31 декабря на сумму непогашенной задолженности собственников по формуле простых процентов;
процентной ставки, начисляемой в связи с ненадлежащим исполнением абонентом обязанности по уплате взносов на капитальный ремонт. Пени должна начисляться, начиная с 11 числа месяца, следующего за текущим. Начисление пени при несвоевременной оплате гражданами взносов в фонд капитального ремонта производится в размере одной трехсотой, действующей на момент оплаты ставки рефинансирования Центрального банка Российской Федерации, от невыплаченных в срок сумм за каждый день просрочки;
процентной ставки, начисляемой по договору размещения средств на банковских счетах. Начисление процентов от размещения средств на банковских счетах происходит ежегодно 31 декабря на сумму собранных собственниками средств по формуле простых процентов.
Процедура открытия и закрытия операционного дня. Подсистема должна позволять производить закрытие операционного дня:
установление признака «закрыт» для текущего операционного дня;
создание нового операционного дня с признаком «открыт»;
запрет на редактирование финансовых документов по закрытому дню;
формирование оборотно-сальдовой ведомости по всем счетам МКД, счету регионального оператора.
По каждому операционному дню должна содержаться как минимум следующая информация:
№
|
Описание
|
Тип
|
Примечание
|
1.
|
Номер
|
Текстовое
|
|
2.
|
Дата операционного дня
|
Дата
|
|
3.
|
Время открытия операционного дня
|
Дата
|
|
4.
|
Время закрытия операционного дня
|
Дата
|
|
Откат операционного дня. В подсистеме должна быть реализована возможность отката операции закрытия операционного дня, т.е. отмена всех финансовых операций, проведенных в текущем операционном дне и возврат всех счетов в состояние на момент создания операционного дня.
Закрытия периода. В подсистеме должен быть реализован учет периодов оплат и операция закрытия периода. В подсистеме должна быть реализована возможность отката операции закрытия периода. При закрытии периода подсистема должна позволять производить закрытие периода:
установление признака «закрыт» для текущего периода;
создание нового периода с признаком «открыт»;
запрет на редактирование финансовых документов по закрытому периоду;
расчет начислений за новый период.
По каждому периоду оплат должна содержаться как минимум следующую информацию:
№
|
Описание
|
Тип
|
Примечание
|
1.
|
Номер
|
Текстовое
|
|
2.
|
Дата открытия периода
|
Текстовое
|
|
3.
|
Дата закрытия периода
|
Текстовое
|
| |
