Материал: Автоматизация обработки заявок Пенсионным Фондом РФ
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
56
Продолжение таблицы №3
Название
справочника
Ответственный
за его ведение
Средний
объём
справочника
в записях
Средняя
частота
актуализации
Средний
объем
актуализации
Пользователи
Администратор
системы ОПФР
-
По
требованию
ОПФР
-
Роли
пользователей
Администратор
системы ОПФР
10
1 год
0 – 1 / год
Территориальные
органы
Администратор
системы
-
По
требованию
ОПФР
-
Определив справочники следует определить реквизитный состав таковых.
Реквизитный состав справочников представим в Таблица 4:
Таблица 4
Адреса
GUID-код ФИАС
Индекс
Регион
Район
Округ
Город
Внутригородской район
Населенный пункт
Улица
Страны Мира
Идентификатор записи
Наименование страны
ОКСМ код
Атрибутный состав справочников
57
Продолжение таблицы 4
Тематики
Идентификатор записи
Наименование тематики
Идентификатор родительской записи
Признак актуальности
Формы
Идентификатор записи
Название формы заявления
Данные формы заявления
Признак актуальности
Пользователи
Идентификатор записи
Идентификатор учетной записи
Фамилия специалиста
Имя специалиста
Отчество специалиста
Идентификатор территориального
органа
Признак актуальности
Роли пользователя
Идентификатор роли
Наименование роли
Параметры доступа
Территориальные органы
Идентификатор записи
Идентификатор регионального
отделения
Наименование отделения / управления
Признак актуальности
ФИО Начальника отделения /
управления
ФИО Бухгалтера отделения /
управления
Адрес отделения / управления
Контактный телефон
58
2.2.3. Характеристика результатной информации
После нажатия кнопки «Зарегистрировать» информация должна передаться в
базу данных на хранение. В данной главе предполагается определить вид
результативной информации и способ ее хранения.
Предполагается хранить данные заявления в формате JSON в специально
выделенном для этого поле. Такое решение даст гибкость в хранении и
использовании данных с сохранением структуры ввода.
Таблица «Регистрации» будет осуществлять хранение данных о регистрации.
Изучив требования к системе нужно предусмотреть быстрый поиск обращений по
базе. Для этой задачи потребуется выделить некоторые данные в отдельные поля:
СНИЛС, фамилия, имя и отчество заявителя, идентификатор территориального
органа, фамилия, имя, отчество специалиста, осуществившего прием, содержание
обращения. Так же следует предусмотреть поле идентифицирующее обращение.
Таблица «Документы» будет осуществлять хранение данных документов, так
как поиск будет осуществляться по документам, то поисковые критерии следует
выделить в отдельные поля: серия, номер, кем выдан, идентификатор документа,
дата выдачи, срок действия.
С помощью описанных таблиц будут автоматически формироваться
выходные документы: заявления(пример изображен на Ошибка! Источник
ссылки не найден.), справки, уведомления(Ошибка! Источник ссылки не
найден.), свидетельство номера индивидуального лицевого счета(СНИЛС)
(Ошибка! Источник ссылки не найден.).
Специфичные данные, такие как номер СНИЛС, справка о выплаченных
пособиях, данные об остатке материнского семейного капитала, справка о
состоянии индивидуального счета и другие формируются только после обработки
системами, предназначенными для этого. Так например данные о материнском
семейном капитале обрабатываются подсистемой «ПС МСК», а данные о пенсиях
и выплатах системой «ПТК НВП». Данные о таких системах должны поступать в
проектную систему, только после этого становится возможным формирование
таковых документов.
59
Рисунок 14 Заявление о выдаче государственного сертификата на материнский семейный капитал
Рисунок 15 Печатная форма СНИЛС
Рисунок 16 Расписка-уведомление формируемое системой
60
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Проектная система носит название Фронт-офис – автоматизированная система
обработки заявок в ПФ РФ. Представляет централизованный сервис (набор
сервисов) осуществляющий регистрацию обращений граждан и их дальнейшую
обработку. Основной задачей системы будет являться централизованная
регистрация с последующим сохранением в БД. Необходимо определить главные
функции регистрации:
Функция создание нового заявления – прием информации из внешнего
источника (архитектура приложения не является монолитной и
представляет собой набор сервисов, поэтому сервис форм является
внешним по отношению сервису регистраций)
Изменение существующего – аналогична функции создания нового
обращения за исключением присвоение нового идентификатора
Чтение данных регистрации – чтение производится из БД с целью передачи
в целевую подсистему, отображения на форме заявления, отображения в
печатных формах.
Аннулирование - изменение атрибута записи в таблице регистрации. Без
физического удаления информации.
Удаление – физическое удаление записи и всех связанных с ней записей из
БД.
Так же необходимо выделить важные задачи, решаемые системой: задачи по
интеграции и задачи печати выходных документов. Целью функций интеграции
являются отправка данных по регистрации в целевую подсистему и прием данных
о результате обработки. Целью функции выходных документов является задача
по подготовке документов с данными регистрации и результатов обработки.
В качестве дополнительных функций можно отметить: функции по созданию
экранных форм, функции поиска, функции статистики. Дополнительные функции
не являются менее важными, но не являются целью системы, являются
вспомогательными. Определив функции системы нужно их систематизировать и
отобразить на дереве функции. Дерево функций изображено на Ошибка!
Источник ссылки не найден.
Источник: https://baza.diplomsite.ru/previewfile/1902