4.2.Требования к функциям СРП
4.2.1.Общие требования к функциям СРП
В рамках работ по созданию СРП необходимо проработать архитектуру системы и способы взаимодействия ее компонентов, разработать структуру БД, а также реализовать в системе следующие возможности:
импорт реестров;
экспорт реестров;
обработка поступивших оплат потребителей;
распределение оплат по начислениям (см. п. 4.2.2);
расчет комиссионного вознаграждения (см. п. 4.2.3);
формирование реестров оплаченных начислений для Центров начислений, поставщиков услуг и других Участников Правил системы;
проведение сверки и корректировки информации о принятых платежах (см. п. 4.2.4);
обработка поручений от Центра начислений;
управление загруженными и загружаемыми реестрами;
предоставление пользовательского интерфейса (см. п. 4.2.5);
протоколирование действий пользователей (см. п. 4.2.7);
управление метаданными системы (см. п. 4.2.8);
формирование и предоставление отчетных форм (см. п. 4.2.9);
проведение сверки;
проведение корректировок;
претензионная работа;
другие возможности, связанные со сбором и расщеплением платежей.
Также СРП должна обеспечить возможность использования единой НСИ в рамках взаимодействия с внешними системами. Детализированные требования к СРП должны быть уточнены на этапе проектирования системы в рамках отдельного ЧТЗ.
Перечень функций и реестров, формируемых СРП:
загрузка реестров платежных реквизитов от Центра начислений;
загрузка реестров начислений от Центра начислений;
реестр начислений от Центра начислений для Сборщика (оффлайн-поиск начислений по реквизитам Плательщика;
онлайн-оплата;
загрузка реестров оплат от Агентов;
реестр оплат по ЕПД;
отмена выполненной оплаты;
реестр платежных поручений для расчетного банка;
реестр выполненных платежных поручений;
отправка реестров оплаченных начислений;
загрузка комиссий по договорам;
загрузка списка услуг Центра начислений;
загрузка списка поручений по корректировкам от Центра начислений;
отправка реестра выполненных перечислений по договорам;
получение информации о неоплаченных начислениях за период в разрезе услуг;
обработка поступивших оплат потребителей.
Должна быть возможность приема и передачи информации в режимах онлайн/оффлайн.
4.2.2.Требования к функции распределения оплат по начислениям
СРП должна выполнять функции по распределению оплат, принятых по ЕПД, между Поставщиками ЖКУ, чьи услуги содержатся в этом ЕПД. Итогом расщепления является распределение поступивших оплат в адрес каждого Поставщика ЖКУ. Правила распределения по каждому Поставщику ЖКУ определяются из справочника алгоритмов распределения платежей.
Должна быть предусмотрена выборочная (частичная) оплата по указанным Плательщиком пакетам услуг. При наличии в реестре оплат информации по пакетам услуг распределение должно производиться с учетом указанных пакетов услуг и указанных сумм оплаты по пакетам услуг.
Для распределения оплат в СРП по каждой услуге устанавливается:
-
Приоритет:
от 1-89, где 1- самый высокий, 89- самый низкий;
99 – специальный алгоритм обработки (например, страхование).
-
Тип оплаты:
1 – полная оплата (невозможна переплата или недоплата);
2 – возможна частичная оплата и возможна переплата;
3 –возможна частичная оплата, но не возможна переплата;
4 – оплата невозможна.
Предельный срок оплаты услуги;
Принадлежность к пакету услуг.
При распределении оплат должны соблюдаться следующие общие принципы:
если есть задолженность/переплата по одной или нескольким услугам, в текущем ЕПД в столбце «К оплате» формируется сумма с учетом этой задолженности/переплаты;
распределение всегда считается по отношению к строке «К оплате».
Плательщик оплатил полную сумму по текущему ЕПД - распределение оплат происходит в полном объеме по отношению к столбцу «К оплате».
Плательщик внес неполную оплату ЕПД - пропорциональное распределение по отношению к столбцу «К оплате».
Плательщик внес сумму больше, чем начислено в ЕПД – оплата в полном объеме текущего ЕПД, остаток средств распределяется как авансовый платеж на будущий период пропорционально суммам по столбцу «Начислено» в текущем ЕПД.
Плательщик вносит сумму текущего ЕПД несколькими платежами в один период – каждая внесенная сумма распределяется пропорционально по отношению к столбцу «К оплате» до полной оплаты ЕПД. В случае переплаты, оставшаяся сумма распределяется как авансовый платеж.
Если на входящем сальдо по отдельным услугам есть переплата, а начисления в текущем периоде меньше суммы переплаты, в столбце «К оплате» по данной услуге будет стоять «0». Соответственно распределение оплаты на данную услугу не производится.
4.2.3.Требования к функции расчета комиссионного вознаграждения
Вознаграждения участников Правил системы не являются постоянными величинами, т.е каждый поставщик ресурса присоединяется к Правилам со своим размером единого тарифа.
При этом единый тариф системы (ЕТС) может быть:
в процентах;
смешанный (процент и фиксированная сумма).
В случае, когда ЕТС выражен в процентах, вознаграждение Оператора системы рассчитывается по остаточному принципу = ЕТС – тариф Сборщика – тариф Центра. Соответственно для расчета тарифа Оператора системы достаточно ввести в Системе соответствующую формулу.
Поскольку в рамках одного региона действует значительное количество агентов по приему платежей, а также по одной услуге может быть множество поставщиков, присоединившихся к Правилам со своим ЕТС, система при распределении вознаграждения должна идентифицировать агента, через которого данный платеж был совершен, чтобы корректно рассчитать вознаграждение Оператора системы.
Кроме того, в случае, когда платеж произведен через агента, не присоединившегося к Правилам системы (т.е. с гражданина платежным агентом комиссия взята «сверху»), комиссия Оператора системы должна рассчитываться по формуле: ЕТС – тариф Центра.
Если ЕТС смешанный (процент (вознаграждение Сборщика и Центра) + фиксированная сумма (вознаграждение Оператора системы)):
Поскольку вознаграждение Центра – постоянная единица, а вознаграждение платежного агента переменная, распределение вознаграждения в рамках систем должно происходить следующим образом:
если комиссия Сборщика равна проценту, заложенному в ЕТС, распределение комиссии осуществляется в размерах, предусмотренных договорами;
если гражданин оплатил ЕПД у агента, комиссия которого меньше, предусмотренной ЕТС, разница направляется в адрес Оператора системы в качестве дополнения к фиксированной сумме вознаграждения;
если гражданин оплатил ЕПД у агента, комиссия которого больше, предусмотренной ЕТС, разница возмещается за счет вознаграждения Оператора системы, выраженного в фиксированной сумме.
Распределение оплат и вознаграждения участников Системы должно осуществляться с учетом следующих особенностей:
Если вся сумма, внесенная плательщиком, приходит в Центр, расщепление платежей поставщикам ЖКУ, а также вознаграждений Сборщику, Центру, Оператору системы осуществляется через СРП.
Если внесенная плательщиком сумма приходит в Центр за минусом комиссии Сборщика, расщепление платежей осуществляется поставщикам ЖКУ, а также вознаграждений Центра и Оператора системы.
4.2.4.Требования к функции сверки и корректировки информации о принятых платежах
СРП должна проводить автоматическую сверку информации о принятых платежах за отчетный период (сутки) на основании итоговых реестров платежей, полученных от Агентов по приему платежей, осуществлять сверку по запросу пользователя, хранить информацию о проведенных сверках.
В случае необходимости изменения данных о принятых платежах Агент по сбору платежей выполняет операцию по отмене или корректировке принятого платежа.
Корректировка оплаты выполняется как парная операция – аннулирование исходной оплаты и ввод новой оплаты с нужными параметрами.
Если отмена или корректировка выполняется в течение того же расчетного дня, в котором была принята оплата, то исходная оплата просто помечается как аннулированная и не участвует в дальнейших расчетах.
Если отмена или корректировка производятся в последующие расчетные дни – аннулирование оплаты выполняется как сторнирование (ввод оплаты с отрицательной суммой), чтобы корректно отразить это аннулирование в расчетах. При этом любая операция аннулирования или корректировки в последующий расчетный день должна быть подтверждена Оператором системы и Поставщиком услуг. Т.е. порядок выполнения операции следующий: Агент по приему платежей, который принял оплату, направляет запрос об аннулировании/корректировке. Оператор системы рассматривает запрос, и отвергает его или направляет в Центр. При подтверждении запроса на аннулирование/корректировку Центром – операция считается одобренной и проводится в СРП.
Претензия – это любое сообщение, связанное с несогласием с суммой платежа, поиском потерянных платежей, взаиморасчетами и т.п. Претензии вводятся в СРП Участниками и рассматриваются Оператором системы, который в свою очередь может направлять их другим Участникам. К претензии могут быть приложены электронные документы, ссылки на платежи или платежные поручения в Системе. Результатом рассмотрения претензии может быть ввод/аннулирование/корректировка оплат или формирование/отмена платежных поручений.
4.2.5.Требования к функциям пользовательского интерфейса СРП
4.2.5.1.Общие требования к функциям пользовательского интерфейса СРП
Пользовательский интерфейс должен содержать следующие разделы:
Импорт
Онлайн-оплата
Реестры
Начисления
Поручения ЦН
Оплаты
Реестры для РБ
Реестры для ЦН
Претензии
Услуги
Договоры
Реквизиты
-
НСИ
Центры начислений
Сборщики
Расчетные банки
Профиль
-
Администрирование
Пользователи
Параметры системы
Параметры и алгоритмы расщепления
Настройка базовых ролей
История посещений пользователей
История действий пользователей
Другие разделы в соответствии с Частным техническим заданием.
Требования к функциональности каждого из разделов описаны в пунктах 4.2.5.2-4.2.5.16 настоящего документа.
Разделы могут содержать списковые формы для работы с сущностями системы. Каждый элемент списка – отдельный экземпляр сущности в БД. Списковые формы должны отображаться как таблицы с набором полей, соответствующих атрибутам сущности. У пользователя должна быть возможность фильтровать и сортировать такие списки в соответствии с набором доступных ему полей. Все списки должны выводиться с разбиением по страницам («пейджинг») с возможность выбора количества выводимых элементов на страницу (50 – по умолчанию, 100, 250, 500).
Атрибутивный состав сущностей, набор полей, набор операций, отображаемых в списковой форме, может уточняться в соответствии с Частным техническим заданием.
Все поля для ввода данных, в том числе и поля для фильтрации, должны поддерживать маски ввода, соответствующие используемому типу данных.
Права доступа к разделам должны определяться ролью пользователя.
Должна быть реализована возможность просмотра истории действий пользователей СРП по каждому элементу списка.
4.2.5.2.Раздел «Импорт»
В данном разделе у пользователя должна быть возможность проводить импорт реестров реквизитов, начислений, оплат, выполненных поручений расчетного банка, договоров, услуг, поручений Центра начислений и других реестров в соответствии с техническими требованиями к форматам реестров, предоставляемыми Заказчиком и Частным техническим заданием.
4.2.5.3.Раздел «Онлайн-оплата»
В данном разделе у пользователя должна быть возможность вносить отдельные платежные поручения (оплаты), которые должны учитываться при последующем распределении оплат по начислениям и расчетах комиссионного вознаграждения.
Ввод данных должен осуществляться с использованием специальной формы, содержащей следующие поля:
Сборщик
Центр начислений
Номер операции
Время платежа
Лицевой счет
Расчетный период
Сумма к оплате
Перечисленная сумма
Комиссия Сборщика
Услуга страхования
Другие поля.
4.2.5.4.Раздел «Реестры»
В данном разделе у пользователя должна быть возможность управлять реестрами системы. Раздел должен содержать списковую форму с реестрами с набором следующих полей:
ID
Код реестра
Отправитель
Дата и время создания / импорта
Расчетный период платежей
Название файла1
Количество записей
Сумма
Статус
Другие поля.
Доступные операции:
Свойства. Переход в карточку реестра.
Данные. Просмотр записей по реестру
Протокол ошибок загрузки для импортируемых реестров. Отображается, только если по реестру есть ошибки. Просмотр ошибок, возникших в процессе загрузки реестра.
Принять (только для импортируемых реестров и реестров онлайн-оплат). Отображается, если реестр в статусе «Загружен», «Загружен с ошибками». Принятие загруженного реестра.
Отклонить/отменить. Отклонение реестра.
Распределить (только для реестра оплат и реестра онлайн-оплат). Отображается, только если реестр не распределен. Распределение оплат по начислениям.
Отменить распределение. Отображается, если возможно отменить распределение;
Отправить (только для исходящих реестров). Отправка реестра с использованием API для взаимодействия с внешними системами. Формат API для взаимодействия с внешними системами предоставляется Заказчиком.
История изменений
Другие операции.
4.2.5.5.Раздел «Начисления»
В данном разделе у пользователя должна быть возможность просматривать список начислений. Раздел должен содержать списковую форму с начислениями с набором следующих полей:
ID
ЦН
Расчетный период
Лицевой счет
Договор
Код ПУ
Принципал
Получатель платежа
ID услуги
Название услуги
Приоритет
Тип оплаты
Начисление, руб.
Сумма к оплате, руб.
Статус
Признак
История изменения
Другие поля
4.2.5.6.Раздел «Поручения ЦН»
В данном разделе должна быть предусмотрена возможность просматривать список и состав реестров по поручениям ЦН на корректировки (зачет переплат, исполнение поручений по письмам поставщиков услуг и принципалам).
Требования к разделу «Поручения ЦН» и доступные действия должны быть разработаны в Частном техническом задании.
4.2.5.7.Раздел «Оплаты»
В данном разделе у пользователя должна быть возможность просматривать список оплат. Раздел должен содержать списковую форму с оплатами с набором следующих полей:
ID
ID агента
ID ЦН
Л/С
Дата и время платежа
Номер
Транзакция
Расчетный период
Сумма к оплате, руб
Сумма платежа, руб
Комиссия, руб
Тип оплаты
Статус платежа
Другие поля
Доступные операции:
Распределить. Используется для распределения конкретной оплаты по начислениям.
Отменить распределение
Отменить оплату
История изменений
Другие операции
4.2.5.8.Раздел «Реестры для РБ»
Функциональность данного раздела аналогична функциональности раздела «Реестры» (см. 4.2.5.4 настоящего документа) за исключением того, что список выводимых реестров ограничен реестрами для расчетного банка.
При формировании поручений в составе реестра должна быть предусмотрена возможность динамического формирования назначения платежа (включение информации об НДС и т.д.).
Должна быть предусмотрена возможность квитования записей реестра поручений записями реестра выполненных поручений и отражение статуса по каждому поручению.
4.2.5.9.Раздел «Реестры для ЦН»
Функциональность данного раздела аналогична функциональности раздела «Реестры» (см. 4.2.5.4 настоящего документа) за исключением того, что список выводимых реестров ограничен реестрами оплаченных начислений и реестрами выполненных платежных поручений.
4.2.5.10.Раздел «Претензии»
Претензия – это любое сообщение, связанное с несогласием с суммой платежа, поиском потерянных платежей, взаиморасчетами и т.п. Претензии вводятся в СРП Участниками и рассматриваются Оператором системы, который в свою очередь может направлять их другим Участникам. К претензии могут быть приложены электронные документы, ссылки на платежи или платежные поручения в СРП. Результатом рассмотрения претензии может быть ввод/аннулирование/корректировка оплат или формирование/отмена платежных поручений.
Требования к разделу «Претензии» и доступные действия должны быть разработаны в Частном техническом задании.
4.2.5.11.Раздел «Услуги»
В данном разделе у пользователя должна быть возможность просматривать список услуг. Раздел должен содержать списковую форму с услугами с набором следующих полей:
ID
Код ЦН
Код услуги
Наименование услуги
Дата и время изменения
Другие поля
4.2.5.12.Раздел «Договоры»
В данном разделе у пользователя должна быть возможность просматривать список договоров. Раздел должен содержать списковую форму с договорами с набором следующих полей:
ID
Код ЦН
Тип договора
Код договора
Принципал
Получатель комиссии
Параметры (содержит значения полей «Процентная ставка», «Мин. сумма», «Макс. сумма», «Фикс. сумма»)
Тип комиссии
Период действия с
Период действия по
Дата и время изменения
Другие поля.
Доступные операции:
Просмотр. Просмотр всех атрибутов договора без возможности редактирования.
Добавить.
Изменить. Просмотр всех атрибутов договора с возможностью редактирования.
История изменений.
Другие операции
4.2.5.13.Раздел «Реквизиты»
В данном разделе у пользователя должна быть возможность просматривать список реквизитов. Раздел должен содержать списковую форму с реквизитами с набором следующих полей:
ID
Код ЦН
Код получателя
Наименование
ИНН
КПП
ОКТМО
Расчетный счет
Наименование банка
БИК
Дата и время изменения
Другие поля
Доступные операции:
Добавить
Изменить. Просмотр всех атрибутов сущности «Реквизиты» с возможностью редактирования.
Другие операции
4.2.5.14.Раздел «НСИ»
Раздел содержит дочерние подразделы:
Центры начислений
Сборщики
Расчетные банки
Центры начислений
В данном разделе у пользователя должна быть возможность просматривать список центров начислений. Раздел должен содержать списковую форму с центрами начислений с набором следующих полей:
ID
Код
Наименование
Правило и алгоритм расщепления
Статус
Другие поля
Доступные операции:
Добавить.
Изменить. Просмотр всех атрибутов сущности «Реквизиты» с возможностью редактирования.
Другие операции.
Сборщики
В данном разделе у пользователя должна быть возможность просматривать список сборщиков. Раздел должен содержать списковую форму со сборщиками с набором следующих полей:
ID
Код
Наименование
Расчетный банк
Статус
Другие поля.
Доступные операции:
Добавить.
Изменить. Просмотр всех атрибутов сущности «Сборщик» с возможностью редактирования.
Пользователи. Просмотр списка пользователей СРП, соответствующих конкретному сборщику.
Другие операции.
Расчетные банки
В данном разделе у пользователя должна быть возможность просматривать список расчетных банков. Раздел должен содержать списковую форму с банками с набором следующих полей:
ID
Код
Наименование
Статус
ЦН
Другие поля.
Доступные операции:
Просмотр
Добавить.
Изменить. Просмотр всех атрибутов сущности «Расчетный банк» с возможностью редактирования.
Другие операции
4.2.5.15.Раздел «Профиль»
В данном разделе у пользователя должна быть возможность изменить свой пароль2 и личные данные:
Имя пользователя
Email
Телефон
Другие поля
4.2.5.16.Раздел «Администрирование»
Раздел содержит дочерние подразделы:
Пользователи
Параметры системы
Настройка базовых ролей
История посещений пользователей
История действий пользователей
Пользователи
В данном разделе должен выводиться список пользователей системы. Список должен содержать следующие поля:
ID
Агент
Роль
Имя пользователя
Логин
Телефон
Email
Статус
Дата регистрации
Вход
На сайте
Другие поля.
Доступные операции:
Добавить
Изменить. Просмотр всех атрибутов сущности с возможностью редактирования.
Роли. Настройка ролей.
Заблокировать. Блокировка пользователя в системе.
История посещений. Ссылка на раздел «История посещений» с фильтрацией по конкретному пользователю.
История действий. Ссылка на раздел «История действий пользователя» с фильтрацией по конкретному пользователю.
Удалить. Удаление пользователя из системы.
Другие операции
Параметры системы
В данный раздел должны быть вынесены все настраиваемые параметры СРП.
Настройка базовых ролей
В данном разделе у пользователя должна быть возможность добавить новую базовую роль и произвести настройку прав доступа индивидуально для каждой роли.
История посещений пользователей
В данном разделе в форме списка должна выводиться история посещений пользователей. Список должен содержать следующие поля:
ID
Имя пользователя
Логин
Email
Роль
Статус
Сеанс
Другие поля
Доступные операции:
Заблокировать. Блокировка пользователя в системе.
История действий. Ссылка на раздел «История действий пользователя» с фильтрацией по конкретному пользователю.
Другие операции.
История действий пользователей
В данный раздел в форме списка должна выводиться история операций, совершенных пользователями системы. Список должен содержать следующие поля:
ID
Имя пользователя
Роль
Действие
Дата действия
Описание
Другие поля
Доступные операции:
Заблокировать. Блокировка пользователя в системе.
История посещений. Ссылка на раздел «История посещений» с фильтрацией по конкретному пользователю.
Другие операции
4.2.6.Защита информации от НСД
доступ к функциональности пользовательского интерфейса только аутентифицированными пользователями в соответствии с их полномочиями;
заведение учетных записей пользователей и управление их правами должно осуществляться уполномоченными администраторами;
управление правами пользователей (создание, хранение, изменение, удаление, назначение ролей и привилегий);
поддержка взаимодействия через программные интерфейсы по протоколу HTTPS;
разграничение доступа к начислениям/платежам в зависимости от назначенных привилегий;
аутентификация пользователей при онлайн-взаимодействии.
разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование СРП;
ограничение неуспешных попыток входа в СРП (доступа к СРП).
4.2.7.Требования к протоколированию действий пользователей
Все операции, совершаемые с любым экземпляром любой из сущностей системы (добавление, редактирование и удаление) должны протоколироваться и записываться в БД системы.
В визуальном интерфейсе системы должна быть предусмотрена возможность просмотра операций по объекту, по пользователю, по произвольному фильтру.
4.2.8.Требования к функции редактирования метаданных
В системе в зависимости от Центра начислений, Сборщика, расчетного банка, другого участника Правил системы и региона эксплуатации могут использоваться различные форматы входящих и исходящих реестров. У пользователя должна быть возможность в режиме визуального проектирования управлять форматами реестров, присутствующих в системе, а также добавлять новые форматы реестров с привязкой к Центру начислений, сборщику, расчетному банку, другому участнику Правил системы и региону эксплуатации.
4.2.9.Требования к функции формирования отчетов
СРП должна обеспечивать:
расчет, выгрузку и передачу в НКО информации, необходимой для перевода денежных средств Участникам Правил системы;
формирование регулярной оперативной отчетности;
автоматическую рассылку/публикацию регулярной отчетности;
выгрузку отчетов в электронном виде.
В системе должна существовать возможность формирования линейных оперативных отчетов с использованием предварительно настраиваемых конфигураций.
Детальные требования к функции формирования отчетов и формам отчетов должны быть уточнены на этапе разработки Частного технического задания.
|
