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

Compare with Current View Page History

Version 1 Next »

О чём раздел

В HRlink есть 3 принципиально отличимые роли, которые имеют свой уникальный набор пользовательских сценариев.

В данном разделе рассматриваются сценарии использования HRlink с точки зрения Сотрудника.

Такая интеграция может быть применена, в случае, если Клиент хочет реализовать функционал HRlink в своей информационной системе (корп.портале)

Мы видим следующие варианты интеграции:

  1. Нативная интеграция - Клиент используя предоставленные API-методы сам реализует интерфейс взаимодействия Сотрудника с HRlink, обеспечивая пользователю работу в одном окне.

  2. Интеграция с редиректами - Клиент использует API-методы для совершения определённых действий, а полученные результаты могут быть переданы пользователю как ссылки для перехода в HRlink

  3. Использование web-view для встраивания интерфейса HRlink в интерфейс ИС Клиента

В описании ниже рассматривается пример нативной интеграции.


Основные задачи Сотрудника

Администратор отвечает за настройку ЛК HRlink. Что именно это означает? Рассмотрим основные функции.

  1. Сотрудник без какой-либо дополнительной роли - 

    Важно


  2. Сотрудник с ролью Руководитель - ...

    Важно

    Под управлением структурой подразумевается:

    1. Юрлица - создание юрлиц
    2. Типы кадровых документов - создание типов документов
    3. МЧД - создание и импорт доверенности, получение реестра всех доверенностей
  3. Кадровый специалист - управляет персоналом.

    Важно

    Под управлением персоналом подразумевается:

    1. Управление ролью Кадровик (назначение и снятие)
    2. Управление областью видимости для Кадровика 
      1. По отделам
      2. По типам документов

1. Сценарии работы Сотрудника с Документами

Цель

...

Предусловие

...

1

API-методы

Примечания

1

 POST /api/v1/clients/:clientId/legalEntities 

Создавать ЮЛ может только пользователь с ролью Администратор

При создании можно указать Идентификатор ЮЛ в ИС Клиента, через поле externalId, это позволит в дальнейшем использовать внутренний (с точки зрения Клиента) идентификатор для работы с ЮЛ.

2

 POST /api/v1/clients/:clientId/departments 

При создании можно указать Идентификатор Отдела в ИС Клиента, через поле externalId, это позволит в дальнейшем использовать внутренний (с точки зрения Клиента) идентификатор для работы с отделами.
3
  • Создание МЧД
    или
  • Импорт МЧД


 

Сценарий

Действия и API-методы

Примечание

1. Сотрудник просматривает данные документа

Цель - предоставить сотруднику всю необходимую информацию по кадровому документу

Предусловие - авторизация произведена

Или используется токен пользователя

1) Получение списка документов для Сотрудника (с учётом фильтров)

POST /api/v1/clients/:clientId/documents/employeeRegistry

На момент составления описания данные метод не оформлен в API-документации see-no-evil monkey

Работа метода (входные параметры для фильтрации и результаты выполнения метода) аналогичны методу получение списка документов для Кадровика (с учётом фильтров)

2) Получение данных документа по ID в своей ИС

GET /api/v1/clients/:clientId/documents/:externalId/externalId

или

GET /api/v1/clients/:clientId/documents/:documentId

Для того, чтобы скачать Печатную форму документа, не скачивая архив, требуется сохранить идентификатор документа в HR-link

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

GET /api/v1/clients/:clientId/documents/:documentId/printFormFile

На момент составления описания данные метод не оформлен в API-документации see-no-evil monkey


2. Сотрудник подписывает (согласовывает) документ через УНЭП по коду из сообщения

Цель - подписать документ, со стороны Сотрудника, как работника компании

Предусловие - выполнен сценарий 1

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

POST /api/v1/clients/:clientId/documents/:documentId/sign/nqes

по итогу вызова данного метода требуется отобразить форму ввода кода


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

PUT /api/v1/clients/:clientId/documents/:documentId/sign/nqes

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

3) Получение данных документа по ID в своей ИС

GET /api/v1/clients/:clientId/documents/:externalId/externalId

или

GET /api/v1/clients/:clientId/documents/:documentId

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

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

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

Подробнее о том, как понять состояние документа см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.1.-%D0%9F%D0%BE%D0%BD%D1%8F%D1%82%D1%8C-%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B5-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8-%D0%BD%D0%B0%D0%B1%D0%BE%D1%80%D0%B0-%D0%BF%D1%80%D0%B8%D0%B7%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2

4) Получение печатной формы документа с оттиском

GET /api/v1/clients/:clientId/documents/:documentId/printFormFile

Для того, чтобы скачать Печатную форму документа, не скачивая архив, требуется идентификатор документа в HR-link


3. Сотрудник отклоняет документ, ожидающий подписания (согласования)

Цель - передать информацию Кадровику о причине отклонения документа

Предусловие - выполнен сценарий 1

1) Отказ от подписания документа

PUT /api/v1/clients/:clientId/documents/:documentId/rejectSigning

Для отклонения подписания обязательным является указание причины - передача не пустого текстового поля, требуется получить от сотрудника текст причины отклонения

2) Получение данных документа по ID в своей ИС

GET /api/v1/clients/:clientId/documents/:externalId/externalId

или

GET /api/v1/clients/:clientId/documents/:documentId

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


4. Сотрудник запрашивает Архив КЭДО по документу

Цель - предоставить Сотруднику все документы по КЭДО в рамках данного документа

Предусловие - выполнен сценарий 1

GET /api/v1/clients/:clientId/documents/:externalId/externalId/archive

или

GET /api/v1/clients/:clientId/documents/:documentId/archive

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


5. Сотрудник подписывает (согласовывает) документ УКЭП

Предусловие - Известен идентификатор документа для подписания

Сотрудник подписывает (прикладывает файл подписи, сформированный во вне HRlink) документ УКЭПом

PUT /api/v1/clients/:clientId/documents/:documentId/sign/externalQes



6. Сотрудник подписывает (согласовывает) документ ПЭП Госуслуги

Предусловие - Известен идентификатор документа для подписания

POST /api/v1/clients/:clientId/documents/:documentId/sign/prr

На момент составления описания данные метод не оформлен в API-документации see-no-evil monkey



Предусловие - Известен идентификатор документа для подписания

PUT /api/v1/clients/:clientId/documents/:documentId/sign/ses

На момент составления описания данные метод не оформлен в API-документации see-no-evil monkey


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

Порядок действий

API-метод

Примечания

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

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

Предусловия

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

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

    1. GET /api/v1/applicationTypes

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

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

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

POST /api/v1/files

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

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


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

Подробнее о методе см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#3.1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BF%D0%B8%D1%81%D0%BA%D0%B0-%D0%A1%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%B4%D0%BB%D1%8F-%D0%B2%D1%8B%D0%B1%D0%BE%D1%80%D0%B0-%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D1%83%D1%8E%D1%89%D0%B5%D0%B3%D0%BE

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

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

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

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

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

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

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

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

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

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

в данный метод передается код, который направляется в сообщении, метод аналогичен методу подтверждения кода для Документа

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

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

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

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

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

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

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

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



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

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

Предусловия

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

    1. GET /api/v1/applicationTypeFields/system

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

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

1) Получены типы Заявлений

GET /api/v1/applicationTypes

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

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


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

Подробнее о методе см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#3.1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BF%D0%B8%D1%81%D0%BA%D0%B0-%D0%A1%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%B4%D0%BB%D1%8F-%D0%B2%D1%8B%D0%B1%D0%BE%D1%80%D0%B0-%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D1%83%D1%8E%D1%89%D0%B5%D0%B3%D0%BE

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

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

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

  • это может быть передача ранее определённых данных

  • это может быть UI форма для заполнения

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

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

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

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

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

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

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

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

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

по итогу вызова данного метода требуется отобразить форму ввода кода

метод аналогичен методу запроса кода для Документа

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

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

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

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

метод аналогичен методу подтверждения кода для Документа

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

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

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

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

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

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

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

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

На данный момент данный метод не оформлен в API-документации see-no-evil monkey


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

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

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

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

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

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

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

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

Метод аналогичен методу получение реестр заявлений для Кадровика

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

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

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

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

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



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

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

  • согласовано

  • отклонено

  • нужно заменить согласующего

Предусловия

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

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

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

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

  • Согласование заявления Согласующим

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

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

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

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

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

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

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

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


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

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



5. Сотрудник (Заявитель) заменяет Согласующего на основании запроса

Цель - скорректировать согласующего, так как предыдущий сотрудник запросил смену согласующего

Предусловия

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

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

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

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

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

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


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

Подробнее о методе см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#3.1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%BF%D0%B8%D1%81%D0%BA%D0%B0-%D0%A1%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%B4%D0%BB%D1%8F-%D0%B2%D1%8B%D0%B1%D0%BE%D1%80%D0%B0-%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D1%83%D1%8E%D1%89%D0%B5%D0%B3%D0%BE

2) Сотрудник передает данные идентификатор нового согласующего

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

На данный момент данный метод не оформлен в API-документации see-no-evil monkey

Замена Согласующего происходит только если Согласующий отметил в Заявлении, что не является Согласующим


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

Цель - предоставить сотруднику архив, содержащий:

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

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

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

Предусловия

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

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




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

  • No labels