You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

О чём раздел


Под сценариями работы Сотрудника с Заявлениями понимаем:

  1. Подачу заявления (из файла или по шаблону) и подписание его УНЭП

  2. Получение данных по Заявлению, в т.ч. архив КЭДО
  3. Обработка заявления - Согласование или Отклонение


Сценарии работы Сотрудника с Заявлениями

1. Сотрудник подает заявление из файла и подписывает его УНЭП

Цель

Предоставить Сотруднику возможность направить заявление, оформленное произвольным образом или по заранее подготовленному файлу.

Предусловия

  1. авторизация произведена

  2. Получены типы Заявлений (для дальнейшего использования id типа "Загрузка из файла" и id участников по этому маршруту)

    1. GET /api/v1/applicationTypes

  3. Определён список сотрудников, для Согласования

    1. GET /api/v2/clients/:clientId/colleagues


API-метод

Примечания

1) Получены типы Заявлений и маршрут подписания REDOC

GET /api/v1/applicationTypes

 

Данный метод предоставляет список типов заявлений, доступных для подачи, а также маршруты подписания по этим типам. Для подачи заявления из файла необходимо выбрать соответствующий тип Заявления - для стандартного типа "Загрузка из файла" всегда указан "templatable": false, для всех остальных типов "templatable": true, поскольку для таких типов существует шаблон.

(warning)  В ответе метода указаны id участников маршрута Заявления (applicationTypes[].signingRouteTemplate{}.stages[].participants[].id), которые необходимо в дальнейшем указывать при создании группы Заявлений (см. п  4)

(info) Типы заявления могут быть стандартными от HRlink, могут быть пользовательскими. Клиент может создать свой тип Заявления и настроить свои заполняемые поля со стороны Заявителя. Также возможно привязать стандартный маршрут от HRlink или создать свой. Создание типа с маршрутом доступно Администратору HRlink. Подробнее про Создание новых типов заявлений.

2) Сотрудник загружает файл для подачи заявления

 REDOC

POST /api/v1/files

Сотрудник заранее создает файл и прикладывает его при оформлении Заявления в системе. После загрузки файла, будет получен идентификатор загруженного файла. Данный идентификатор надо передать в методе создания группы заявлений. (см. п  4)

3) Сотрудник выбирает кто будет согласовывать заявление


Определить Согласующих возможно несколькими способами:

  1. На основании метода GET /api/v2/clients/:clientId/colleagues из полученного списка выбирается тот, кто будет передан в метод создания Заявления как Согласующий (метод не описан на текущий момент)

  2. Возможно указать participants[].employeeExternalId - идентификатор сотрудника внешней системы, в качестве участника маршрута при подаче заявления (см. п  4). (warning)  На момент подачи Заявления employeeExternalId сотрудников должны быть переданы в HRlink.

4) Сотрудник подаёт заявление из загруженного файла REDOC

POST /api/v1/clients/:clientId/applicationGroups

(warning) Необходимо указать id типа заявления и id участников маршрута подписания (см.п.1).

Система сама сконвертирует загруженный файл в pdf/a формат для дальнейшего подписания.

В ответе будет получен идентификатор заявления, его можно использовать при завершении процесса для отображения формы заявления

5) Запуск подписания Заявления УНЭП - запрос сообщения с кодом

 REDOC

POST /api/v1/clients/:clientId/applicationGroups/:applicationGroupId/sign/nqes

На активный канал получения кода подписания Сотрудника будет выслан код для подписания УНЭП. После - сотруднику необходимо ввести код и передан его для проверки, поэтому по итогу вызова данного метода требуется отобразить форму ввода кода.

(info) Канал получения кода подписания устанавливается при выпуске УНЭП Сотруднику. 

6) Завершение подписания Заявления УНЭП - подтверждение кода из сообщения REDOC

PUT /api/v1/clients/:clientId/applicationGroups/:applicationGroupId/sign/nqes

Передача кода для проверки в УЦ.

Результат проверки кода не возвращается в ответе метода, т.к. процесс асинхронный. Требуется опрашивать статус Заявления для продолжения процесса. Подробнее про состояния Заявления.

7) Получение данных Заявления REDOC

GET /api/v2/clients/:clientId/applicationGroups/:applicationGroupId


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

  1. получить обновление по статусу

  2. перейти к запросу печатной формы с оттиском

8) Получение печатной формы заявления с оттиском REDOC

GET /api/v1/clients/:clientId/applications/:applicationId/printFormFile



2. Сотрудник подаёт заявление по шаблону и подписывает его УНЭП

Цель

Предоставить Сотруднику возможность направить заявление, по заранее определённому шаблону, ожидающему заполнения заданных полей.

Предусловия

  1. Шаблон типа заявления создан, активен и доступен для отдела Сотрудника REDOC (info) Подробнее про работу с типами Заявлений
    1. POST /api/v1/applicationTypes
    2. PUT /api/v4/applicationTypes/{applicationTypeId}

  2. Получены системные поля  REDOC

    1. GET /api/v1/applicationTypeFields/system

  3. Определён список сотрудников, для Согласования

    1. GET /api/v1/clients/:clientId/colleagues

API-метод

Примечания

1) Получены типы Заявлений и маршрут подписания REDOC

GET /api/v1/applicationTypes

Данный метод предоставляет список типов заявлений, доступных для подачи, а также маршруты подписания по этим типам. Для подачи заявления из файла необходимо выбрать соответствующий тип Заявления.

(info) Типы заявления могут быть стандартными от HRlink, могут быть пользовательскими. Клиент может создать свой тип Заявления и настроить свои заполняемые поля со стороны Заявителя. Также возможно привязать стандартный маршрут от HRlink или создать свой. Создание типа с маршрутом доступно Администратору HRlink. Подробнее про Создание новых типов заявлений.

(warning)  Во всех типах с флагом "templatable": true указаны параметры заполняемых, пользовательских полей, в том числе и идентификаторы этих полей applicationTypes[].templateFields[].id. Эти id необходимо в дальнейшем указывать при создании группы Заявлений (см. п  4) вместе с данными, которые заполнил Заявитель.

(warning) В ответе метода указаны id участников маршрута Заявления (applicationTypes[].signingRouteTemplate{}.stages[].participants[].id), которые необходимо в дальнейшем указывать при создании группы Заявлений (см. п  4)

2) Получен справочник системных полей REDOC

GET /api/v1/applicationTypeFields/system

 

Данный метод возвращает перечень системный полей, которые могут предзаполняться в шаблоне Заявления. Например, ФИО Сотрудника (Заявителя), наименования юр.лица, отдела, должности, текущая дата и т.д.

(warning) Каждое системное поле имеет свой идентификатор. Эти id необходимо в дальнейшем передать при создании группы Заявлений (см. п  4) вместе с данными, которые автоматически заполнились системой. Заполнить поля возможно, использовав метод Получения информации о текущем пользователе, например.

(info)  Подробнее про системные поля.

3) Сотрудник выбирает кто будет согласовывать заявление


Определить Согласующих возможно несколькими способами:

  1. На основании метода GET /api/v2/clients/:clientId/colleagues из полученного списка выбирается тот, кто будет передан в метод создания Заявления как Согласующий (метод не описан на текущий момент)

  2. Возможно указать participants[].employeeExternalId - идентификатор сотрудника внешней системы, в качестве участника маршрута при подаче заявления (см. п  4). (warning)  На момент подачи Заявления employeeExternalId сотрудников должны быть переданы в HRlink.

4) Создание заявления по шаблону REDOC

POST /api/v1/clients/:clientId/applicationGroups

На основании того, какой был выбран тип (шаблон) заявления, необходимо заполнить обязательные поля:

  • это может быть передача ранее определённых данных, таких как ФИО, отдел, должность и т.д. в качестве системных полей templateSystemFields

  • это может быть передача данных, которые Сотрудник ввел на UI форме, например, даты отпуска, тип отпуска, новое название отдела при переводе и т.д..  Такие поля передаются как templateFields 

(warning) Необходимо указать id заполняемых полей, системных (см.п.2) или пользовательских (см.п 1), а также тип заявления и id участников маршрута подписания (см.п.1).

(warning) Идентификатор файлаfileId - не заполняется, т.к. Система сама формирует файл заявления и конвертирует его в pdf/a формат для последующего подписания.

5) Получение данных Заявления REDOC

GET /api/v2/clients/:clientId/applicationGroups/:applicationGroupId

После того, как создано заявление, система формирует pdf файл, который можно отобразить для проверки перед подписанием

6) Загрузка файла заявления, сформированного по шаблону REDOC

GET /api/v1/clients/:clientId/applications/:applicationId/convertedFile

Данный этап не является обязательным, но позволяет Сотруднику увидеть, что получилось по итогу заполнения полей шаблона заявления, если результат устраивает - переход к шагу 7, в случае если результат не устраивает - переход к шагу 2

7) Запуск подписания Заявления УНЭП - запрос сообщения с кодом

 REDOC

POST /api/v1/clients/:clientId/applicationGroups/:applicationGroupId/sign/nqes

На активный канал получения кода подписания Сотрудника будет выслан код для подписания УНЭП. После - сотруднику необходимо ввести код и передан его для проверки, поэтому по итогу вызова данного метода требуется отобразить форму ввода кода.

(info) Канал получения кода подписания устанавливается при выпуске УНЭП Сотруднику. 


8) Завершение подписания Заявления УНЭП - подтверждение кода из сообщения REDOC

PUT /api/v1/clients/:clientId/applicationGroups/:applicationGroupId/sign/nqes

Передача кода для проверки в УЦ.

Результат проверки кода не возвращается в ответе метода, т.к. процесс асинхронный. Требуется опрашивать статус Заявления для продолжения процесса. Подробнее про состояния Заявления.


9) Получение данных Заявления REDOC

GET /api/v2/clients/:clientId/applicationGroups/:applicationGroupId

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

  1. получить обновление по статусу

  2. перейти к запросу печатной формы с оттиском

10) Получение печатной формы заявления с оттиском REDOC

GET /api/v1/clients/:clientId/applications/:applicationId/printFormFile


3. Сотрудник просматривает Заявление

Цель

Предоставить Сотруднику всю информацию по заявлению

Предусловия (одно из)

  • Заявление подано сотрудником

  • Сотрудник является согласующим 


API-метод

Примечания

1) Сотрудник загружает список заявлений, в соответствии с фильтрами REDOC

POST /api/v2/clients/:clientId/applicationGroups/getEmployeeRegistry


2) Получение данных Заявления REDOC

GET /api/v2/clients/:clientId/applicationGroups/:applicationGroupId

Данный метод возвращает метаданные заявления, но не файл для просмотра

3) Получение печатной формы заявления с оттиском REDOC

GET /api/v1/clients/:clientId/applications/:applicationId/printFormFile

Этот шаг не обязательный, но позволяет наглядно увидеть кто и когда совершал действия по Заявлению. 


4. Сотрудник Обрабатывает заявление как Согласующий

Цель

Предоставить ответственному сотруднику возможность принять решение по заявлению:

  • согласовать

  • отклонить

 

Предусловия

  1. Заявление подано сотрудником (создано и подписано)

  2. Текущий пользователь является согласующим 

  3. выполнен сценарий - Сотрудник просматривает Заявление


API-метод

Примечания

1) Сотруднику, который указан согласующим при просмотре заявления, ожидающего согласования необходимо предоставить выбор совершаемого действия:

PUT /api/v1/clients/{clientId}/applications/{applicationId}/signBySes 

PUT /api/v1/clients/{clientId}/applications/{applicationId}/reject

После согласования Заявления со стороны Согласующего, Заявление продолжает свое движение по маршруту подписания, т.е. следующий подписант получит уведомление о том, что Заявление ожидает от него решения. Если Согласующий является последним по маршруту, то документооборот по Заявлению завершен. 

(info) Как правило последний участни по маршруту  - это кадровый специалист, который и завершает обработку Заявления.

2) Получение печатной формы заявления с оттиском REDOC

GET /api/v1/clients/:clientId/applications/:applicationId/printFormFile

Этот шаг не обязательный, но позволяет наглядно увидеть, что операция отразилась в оттиске.



5. Сотрудник загружает архив КЭДО по Заявлению


Цель

Предоставить сотруднику архив, содержащий:

  • файл который подписывался

  • печатную форму с оттисками

  • файл подписи


Предусловия

  1. выполнен сценарий - Сотрудник просматривает Заявление


API-метод

Примечания

GET /api/v1/clients/:clientId/applications/:applicationId/archive





Поиск документации

  • No labels