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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В данный метод передается код, который направляется в сообщении

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

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

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

PUT /api/v1/clients/:clientId/applications/:applicationId/participants/approver/reject

• Запрос на замену согласующего

PUT /api/v1/clients/:id/applications/:applicationId/participants/approver/rejectApproving

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

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

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