Технические требования


НазваниеТехнические требования
страница8/15
ТипДокументы
filling-form.ru > бланк заявлений > Документы
1   ...   4   5   6   7   8   9   10   11   ...   15

Специальные возможности

      1. Промежуточные запросы к сервису при заполнении ИФ


В ходе заполнения заявления может возникнуть необходимость сделать запрос к сервису ведомства для получения дополнительной информации для отображения пользователю. При этом следует избегать и минимизировать подобные взаимодействия, по причине замедления процесса заполнения формы и зависимости возможности заполнения заявления от доступности сторонних для ЕПГУ сервисов и систем.
      1. Использование словарей

1.1.1.1.Встроенные словари 


На интерактивных формах может потребоваться выбор значений из справочников.

Компоненты, реализующие данную функциональность содержатся в библиотеках типового функционала ЕПГУ и их изменение не рекомендуется.

Справочники могут иметь плоскую (одноуровневую) или иерархическую (многоуровневую) структуру. Иерархия может быть как внутри одного справочника, так и между несколькими справочниками.

На форме заявителю доступен выбор единственного элемента из значений справочника.

В случае если справочник содержит малое количество значений (в пределах 5), с точки зрения пользователя, удобнее представлять его на интерактивной форме в виде радиокнопок.

Справочники можно разделить на несколько типов:

Общероссийские справочники, состав которых закреплен нормативными документами. К ним относятся: ОКАТО – справочник территорий, ФИАС – справочник адресов, ОКСМ – общероссийский классификатор стран мира.

Справочники, специфические для ведомства (ОИВ). В случае если справочник не обновляется и содержит не более 500 значений, его возможно хранить в БД ЕПГУ. В этом случае необходимо в разделе «Приложение 1» технического описания интерактивной формы (на услугу) привести описание справочника.

Описание ведомственного справочника рекомендуется предоставить в виде файла с расширением .csv (в качестве разделителя должна быть выбрана запятая). Файл должен содержать 6 столбцов в определенном порядке:

1. Код  - Код элемента, который необходимо присвоить элементу справочника. Внутри справочника коды элементов должны быть уникальны. Данный атрибут обязателен для каждого элемента.

2.    Название – Название элемента справочника, т.е. то, что будет отображаться пользователю на форме. Данный атрибут обязателен для каждого элемента.

3.    Код родительского элемента – Родительский элемент, на который ссылается текущий. Необходимо, чтобы код самого родительского элемента содержался в первом столбцев одной из строк таблицы. Также, необходимо избегать циклических зависимостей: т.е. чтобы родительский элемент не ссылался на дочерний элемент, как на родителя.
Если хотя бы у одной из строк в столбце «Код родительского элемента» не пусто, значит, тип справочника – многоуровневый, иначе, справочник  одноуровневый.

4.    Дополнительный код – Например, внешний код элемента справочника.

5.    Порядковый номер – Номер элемента в справочнике, может использоваться для вывода элементов на форму с учетом указанного порядка.

6.    Статус – Активный или деактивированный элемент { A , D }.

Пример файла, содержащего описание справочника:



Файл должен быть приложен в разделе «Приложение 1» технического описания интерактивной формы (на услугу).

Допускается описание справочника в виде таблице в разделе «Приложение 1» технического описания интерактивной формы (на услугу).

Таблица 3 Пример представления справочника ведомства в техническом описании интерактивной формы

Название справочника

Код элемента справочника (передаваемый в ИС ФОИВ)

Значение элемента справочника

Порядковый номер элемента в справочнике

Калибр оружия

1057X

10,57X72

1

57X

5,7X49

2

Типы лицензий и разрешений

RLSA

Разрешение на хранение и ношение при исполнении служебных обязанностей. Служебного оружия

1

RNGA

Разрешение на право хранения и ношения наградного оружия

2


Таблица 4 Пример представления иерархического справочника ведомства в техническом описании интерактивной формы

Название справочника

Код родительского элемента справочника (пустой для корневых элементов)

Код элемента справочника (передаваемый в ИС ФОИВ)

Значение элемента справочника

Порядковый номер элемента в справочнике

Отделения службы судебных приставов

-

77000

УФССП по г. Москва

1

-

02000

УФССП по Республике Адыгея

2

02000

02001

Майкопский ГОСП

3


В случае если справочник содержит один дополнительный атрибут, который должен присутствовать на интерактивной форме (например, Регион (субъект РФ) и Наименование соответствующего ему территориального отделения ОИВ), это может быть реализовано на стороне ЕПГУ (храниться в БД ЕПГУ) в виде двух справочников, между которыми установлена иерархия (для приведенного примера справочник «Регионы» будет являться родительским, справочник «Территориальные отделения ОИВ» - дочерним).

1.1.1.2.Вызываемые словари


В случае если справочник содержит дополнительные атрибуты (более одного), которые должны присутствовать на интерактивной форме, его необходимо получать от сервиса органа власти. Шаблон, преобразующий данные, полученные от сервиса ведомства в формат типового элемента формы, разрабатывается для каждого ведомственного справочника (или ИФ).

В случае если справочник ИС ФОИВ часто обновляется (пополняется) или содержит большое количество элементов, ФОИВ необходимо реализовать отдельный вид сведений для получения значений справочника, и зарегистрировать его в СМЭВ 3.0.

В случае если справочник является динамическим (например, запись граждан на прием в ведомстве, запись в ГИБДД, и т.д.), также необходимо реализовывать отдельный вид сведений для получения значений справочника, и зарегистрировать его в СМЭВ 3.0.

Сообщения, содержащие запросы к виду сведений для получения значений справочника, должны соответствовать использованной при регистрации вида сведений версии методических рекомендаций по работе с Единой системой межведомственного электронного взаимодействия версии 3.0.

Примеры запросов приведены в Приложении 2.
      1. Работа с ЭП


Согласно методическим рекомендациям по работе с Единой системой межведомственного электронного взаимодействия версии 3.0. все заявления, отправляемые с ЕПГУ в ИС ФОИВ, подписываются электронной подписью ЕПГУ (подписывается блок SenderProvidedRequestData сообщения). При наличии соответствующих требований заявление и приложенные к нему файлы могут подписываться ЭП пользователя.

Для всех интерактивных форм устанавливается один из признаков работы с ЭП заявителя:

Подпись заявления ЭП заявителя не требуется.

Подпись заявления личной подписью заявителя обязательна.

В случае если подпись заявления обязательна, после заполнения всех полей интерактивной формы пользователь выполняется подписание ЭП заявления в следующей последовательности:

Пользователю отображается шаг просмотра и подписания всех приложенных к заявлению документов (см. рис. 15);

После подписания выполняется возвращение на форму заявления;

Пользователю отображается шаг просмотра и подписания заявления.



Рисунок 27. Шаг услуги с подписанием заявления и вложений ЭП

Подписание документов возможно только в том случае, если пользователь подтвердил факт просмотра всех подписываемых документов.

При клике на кнопку «Подписать» у пользователя запрашивается ПИН-код электронного носителя ЭП (пароль, выдаваемый вместе с электронным носителем ЭП):



Рисунок 28. Модальное окно для ввода ПИН-кода электронного носителя ЭП

В случае успешного формирования подписи пользователю отобразятся сведения о сформированных электронных подписях:



Рисунок 29. Информационный блок, содержащий сведения об электронных подписях

При клике на кнопку «Вернуться» происходит возврат на интерактивную форму заявления, с которого осуществлялся переход на подписание ЭП.

Компоненты, реализующие данную функциональность, относятся к общему функционалу ЕПГУ и не подлежат изменению при разработке ИФ.
      1. Пописание ЭП заявителя


В виде сведений должен быть предусмотрен блок описания прилагаемых файлов:

Группа вложений описывается элементом запроса вида сведений AppliedDocuments.

Каждое вложение описывается одним элементом AppliedDocument.

Каждый элемент AppliedDocument должен содержать следующие элементы:

Имя поля

Тип поля

Назначение

CodeDocument

digits-4

Номер документа.

Name

string-200

Имя файла загруженного документа.

URL

string-200

Относительный путь к файлу внутри архива.

BusinessName

string-200

Имя приложения в соответствии с бизнес-правилами

Type

string-200

Тип контента (например: application/pdf или любой другой общепринятый MIME-тип)

DigestValue

string-100

Хэш файла в соответствии с ГОСТ

Все типы полей указаны в пространстве имен urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1.

Поле URL формируется из мнемоники элемента «Загрузка файла».

Поле BusinessName формируется из атрибута «Бизнес-наименование документа» элемента управления «Загрузка файла».

Атрибут «Бизнес-наименование документа» элементов «Загрузка файла» указывается в соответствии с атрибутом «Название переменной в XML» описания полей (раздел 5 типового Технического задания на размещение услуги). Бизнес-наименования документов должны быть уникальны в рамках формы. При использовании поля «клонируемая панель» с элементами «Загрузка файла» бизнес-наименования элементов остаются неизменными во всех клонируемых панелях.

Файл XML-запроса вида сведений в блок описания вложений не вносится.

Ниже схема данных в формате ERD на примере запроса EIPApprovalRequestService.



Рисунок 30 схема данных описания вложений

Из файлов и ЭП в формате PKCS#6 detached ЕПГУ сформирует архив в формате zip содержащий:

Заявление в информационную систему Поставщика вида сведений в формате запроса вида сведений с описью прилагаемых файлов.

Электронную подпись пользователя ЕПГУ, соответствующую файлу заявления на основе стандарта PKCS#7 (detached).

Вложения в виде файлов форматов, согласованных с поставщиком сервиса (при наличии);

Электронные подписи пользователя ЕПГУ, соответствующие каждому из файлов вложений, передаваемых в архиве, на основе стандарта PKCS#7 (etached).

Имя файла заявления в формате XML вкладываемого в архив фиксировано: Request.xml.

Файл заявления должен лежать в корневом каталоге архива.

Имя архива является фиксированным: SignedContent.zip.

Электронные документы и их электронные подписи могут находиться на любом уровне вложенности в архиве, но пути должны быть указаны в xml-файле заявления в соответствии с форматом, указанным выше.

Файлы электронной подписи для заявлений и вложений в формате PKCS#7 (detached) имеют формализованное правило именования, при котором к имени исходного файла добавляется постфикс *.sig.

Пример именования файла подписи указан в таблице ниже.

Наименование файла

Наименование файла подписи

Request.xml

Request.xml.sig

attachment.txt

attachment.txt.sig

Подписание производится КСКП заявителя в соответствии с требованиями п. 4.2.1 МР СМЭВ 3, и в соответствии с правилами 4.4.2.1 МР СМЭВ 3.

Запрос вида сведений, передаваемый в составе СМЭВ 3-конверта (//MessagePrimaryContent) и в архиве должны быть полностью идентичны.
1   ...   4   5   6   7   8   9   10   11   ...   15

Похожие:

Технические требования iconТехнические требования
...

Технические требования icon1 Технические, экономические и другие требования, предъявляемые к выполняемым исполнителем

Технические требования iconСодержание
Технические требования к оборудованию pe-маршрутизаторов (Business pe, rgr) магистральной

Технические требования iconСодержание
Технические требования к оборудованию pe-маршрутизаторов (Business pe, rgr) магистральной

Технические требования iconЕдиные функционально-технические требования к региональному информационному...
Единые функционально-технические требования к региональному информационному ресурсу, обеспечивающему прием заявлений, учет детей,...

Технические требования iconЕдиные функционально-технические требования к региональному информационному...
Единые функционально-технические требования к региональному информационному ресурсу, обеспечивающему прием заявлений, учет детей,...

Технические требования iconТехническое задание москва 2015 содержание введение Функциональные...
Функциональный объем и требования к разрабатываемому продукту сформированы на основании бизнес-требований, утвержденной целевой технической...

Технические требования iconАнкета Участника (Форма 2) 22
Технические требования к Товару, подтверждение соответствия продукции предъявляемым требованиям 5

Технические требования iconРасшифровка арм
Технические требования по подключениЮ информационных систем операторов технического осмотра к еаисто

Технические требования iconБизнес Парк "Румянцево"
Технические требования к рекламе (вид, формат, технологические параметры, хронометраж и т д.)

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск