Основные сценарии управления персоналом

Примечание

Кадровик создаёт учётные записи пользователей и приглашает к подтверждению

Кадровик обновляет данные ФЛ (канал уведомления) и отправляет приглашение на новый канал

Кадровик управляет ролью Руководитель

 Вариант 1. Кадровик создает сотрудника с ролью Руководитель

 Вариант 2. Кадровик при обновлении сотрудника назначает роль Руководитель

 Вариант 3. Кадровик добавляет/убирает роль Руководитель для Сотрудника

Сценарии работы Кадровика с

уже сформированными данными Сотрудников

Кадровик получает данные Сотрудников

Определение состояния Учётной записи и наличия ЭП

Цель сценариев - Кадровик назначает роль Руководитель сотрудникам, чтобы они в последствии могли подписывать документы от имени компании

Пользовательский Сценарий

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

Примечания

0. Подготовительный этап

Цель - иметь возможность назначать роль по идентификатору

1) Кадровик получает список ролей сотрудников

GET /api/v1/employeeRoles

данные могут использоваться в сценариях создания с ролью, обновления с указанием роли и добавления роли

2) Получение полного списка справочника сотрудников

GET /

api/v1/clients/:clientId/employees

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

1. Кадровик создает сотрудника с ролью Руководитель

/getRegistry  или Получение данных физлица по номеру СНИЛС Status subtle true colour Green title redoc  GET

1) Кадровик при создание Сотрудника на основании Физ.лица задает роль Руководитель

POST

/api/v1/clients/:clientId/

employees

пояснения к запросу смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%A1%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%B0-%D1%81-%D1%80%D0%BE%D0%BB%D1%8C%D1%8E

users/:snils/snils  или Получение данных сотрудника по ID своей ИС Status subtle true colour Green title redoc  GET /api/v1/clients/:

2. Кадровый при обновлении сотрудника назначает роль Руководитель

1) Кадровик обновляет сотрудника по ID своей ИС

PUT /api/v1/clients/:

clientId/employees/:externalId/

externalId

externalId  или

Кадровик обновляет

Получение данных сотрудника по ID HRL

Status subtle true colour Green title redoc  GET

PUT

/api/v1/clients/:clientId/employees/:employeeId

3. Кадровик добавляет/убирает роль Руководитель для Сотрудника

Expand title Понять состояние учётной записи На примере метода (фильтрационные параметры можно посмотреть в документации)  POST

1) Добавление роли

PUT

/api/v1/clients/:clientId/employees/

:employeeId/roles/add

или

• Удаление роли

PUT /api/v1/clients/:clientId/employees/:employeeId/roles/remove

На момент подготовки описания метод - не описан в АПИ-доке

методы добавления/удаления роли действуют только по идентификатору Сотрудника в HRlink

Сценарии работы Кадровика с уже сформированными данными реестра Сотрудников

```
{
    "result": true,
    "employees": [
		{
            "lastName": "Фамилия",
            "firstName": "Имя",
            "patronymic": "Отчество",
            "gender": "MALE",
            "birthdate": "1966-01-01",
            "personalDocuments": [...],
            "notificationChannels": [
                {
                    "id": "5989b950-382b-4492-a7fd-2284ad0923e6",
                    "login": "some@mail.ru",
                    "type": "EMAIL",
                    "confirmed": false,
                    "priority": 0,
                    "enabled": false,
                    "invited": true,
                    "version": 1
                }
            ],
            "certificates": [],
            "lastNqesIssueRequest": null,
            "invitation": {
                "type": "EMAIL",
                "invitationCreatedDate": "2022-10-18T09:23:12.087136Z"
            },
            "prrSigningEnabled": false,
            "govKeySigningEnabled": false,
            "qesSigningEnabled": false,
            "vtbSigningEnabled": false,
            "disabledDate": null,
            "lastNqesChannelChangeRequest": null,
            "id": "e67ae253-8000-4bd6-97ee-fe35005d897d",
            "externalId": "66b457c9-7c02-11e2-9362-001b11b25590",
            "clientUser": {...},
            "dismissedDate": null,
            "scheduledDismissDate": null,
            "legalEntity": {...},
            "department": {...},
            "position": {...},
            "roles": [...],
            "tags": [],
            "permittedOperations": [...],
            "headManager": false,
            "availableVacationDayCount": null,
            "number": null,
            "version": 2
		},
		...
}
```

```
{
    "result": true,
    "employees": [
		{
            "lastName": "Фамилия",
            "firstName": "Имя",
            "patronymic": "Отчество",
            "gender": "MALE",
            "birthdate": "1966-01-01",
            "personalDocuments": [...],
            "notificationChannels": [...],
            "certificates": [
			    {
                    "lastName": "Фамилия",
                    "firstName": "Имя",
                    "patronymic": "Отчество",
                    "type": "NQES",
                    "fingerprint": "3c46f97819a8ff7e0f0cf9e0f44ad7d67f130ec5",
                    "companyName": "Баранов Лев Леонидович",
                    "expiresDate": "2023-12-12T10:24:36.000000Z",
                    "personIdentificationType": "IN_PERSON",
                    "id": "06e121a5-5c6f-4e80-b89a-0515ccd5c62e",
                    "validAfterDate": "2022-12-12T10:24:43.000000Z",
                    "confirmationChannelType": "SMS",
                    "confirmationChannel": "+79223230530"
                }
			],
            "lastNqesIssueRequest": {
			    "nqesIssueTaskId": "8b174531-00c5-4e34-971c-a5a0d4e7c70f",
                "fingerprint": null,
                "state": "APPLICATION_CREATED",
                "createdDate": "2021-11-12T09:30:57.945733Z",
                "applicationCreationStartedDate": "2021-11-12T09:30:58.359633Z",
                "applicationCreatedDate": "2021-11-12T09:31:02.128140Z",
                "userNotifiedAboutIssueRequestDate": null,
                "issuingConfirmedDate": null,
                "issuingRejectedDate": null,
                "printFormCreationStartedDate": null,
                "printFormCreatedDate": null,
                "nqesIssueRequestCreatedDate": null,
                "nqesIssueRequestFailedDate": null,
                "nqesIssuedDate": null,
                "userNotifiedAboutCertificateDate": null,
                "certificateAcceptedDate": null,
                "certificateDeclinedDate": null,
                "finishedDate": null,
                "canceledDate": null,
                "personIdentificationType": "IN_PERSON",
                "nqesConfirmationChannel": {
                    "type": "SMS",
                    "value": "+79217823607"
                },
            "invitation": {...},
            "prrSigningEnabled": false,
            "govKeySigningEnabled": false,
            "qesSigningEnabled": false,
            "vtbSigningEnabled": false,
            "disabledDate": null,
            "lastNqesChannelChangeRequest": null,
            "id": "e67ae253-8000-4bd6-97ee-fe35005d897d",
            "externalId": "66b457c9-7c02-11e2-9362-001b11b25590",
            "clientUser": {...},
            "dismissedDate": null,
            "scheduledDismissDate": null,
            "legalEntity": {...},
            "department": {...},
            "position": {...},
            "roles": [...],
            "tags": [],
            "permittedOperations": [...],
            "headManager": false,
            "availableVacationDayCount": null,
            "number": null,
            "version": 2
		},
		...
}
```

Обновление данных Физлица

Обновление данных Сотрудника

Увольнение Сотрудника

```
{
    "roleId": "fcaa233d-93c9-4545-a5b6-4ccd78b1a9b0"
}
```

```
{
    "result": true
}
```

Восстановление уволенного Сотрудника

```
{
    "version": 1 // необзательный параметр
}
```

```
{
  "result": "bool",
  "employee": {...}
}
```

Перевод Сотрудника

Сценарии работы Кадровика с Электронными подписями

Выпуск УНЭП

```
{
    "value": "...."
}
```

```
{
    "result":true,
    "request":{
		"id":"8f2afc36-82ff-43fa-924b-6eff5bf05568"
	}
}
```

Использование иных видов ЭП

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

Пользовательский Сценарий

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

Примечания

1. Кадровик получает данные Сотрудников

Цель сценариев - получить данные по пользователям (список сотрудников, их данные и их состояния), по которым организован КЭДО в HRL.

1) Получение полного списка справочника сотрудников

GET /api/v1/clients/:clientId/employees

Кадровик получит список тех сотрудников (или данные того сотрудника), кто привязан к отделам, видимым для данного Кадрового работника.

См. схему логических связей

Подробное описание ответа см. в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#2.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%9F%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-%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

2) Получение данных физлица по номеру СНИЛС

GET /api/v1/clients/:clientId/users/:snils/snils

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

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

или

• Получение данных сотрудника

GET /api/v1/clients/:clientId/employees/:employeeId

2. Кадровик обновляет данные Физлица

Цель - обновление таких данных как:

• ФИО

• Паспортные данные и данные документов (СНИЛС, ИНН)

• Данные для Уведомления и Авторизации, в т.ч. удаление канала уведомления

1) Обновление физлица по ID своей системы

PUT /api/v1/clients/:clientId/users/:externalId/externalId

или

• Полное обновления физлица

PUT /api/v1/clients/:clientId/users/:clientUserId

Данный шаг сценария позволяет вносить изменения в данные ФЛ:

• паспорт

• снилс

• инн

• фио

2) Установка канала уведомления сотрудника как активного

PUT /api/v1/clients/:clientId/users/:clientUserId/notificationChannels/:channelId/activate

или

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

DELETE /api/v1/clients/:clientId/users/:clientUserId/notificationChannels/:channelId

Данный шаг сценария позволяет вносить изменения в данные по каналам уведомления

3. Кадровик обновляет данные Сотрудника

Цель - обновление таких данных как:

• Отдел

• ЮЛ

• Должность

• Роль - Сотрудник или Руководитель

1) Кадровик обновляет данные сотрудника по ID своей ИС

PUT /api/v1/clients/:clientId/employees/:externalId/externalId

или

• Кадровик обновляет данные одного сотрудника

PUT /api/v1/clients/:clientId/employees/:employeeId

4. Кадровик присваивает почту/телефон от одного Сотрудника - другому сотруднику для приглашения

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

1) Удаление канала уведомления Пользователя

DELETE /api/v1/clients/:clientId/users/:clientUserId/notificationChannels/:channelId

Удаление подтверждённого канала уведомление приведёт к освобождению занимаемого логина, что позволит использовать его для другого работника.

2) Обновление физлица по ID своей ИС

PUT /api/v1/clients/:clientId/users/:externalId/externalId

5. Кадровик увольняет Сотрудника

Цель - прекращение деятельности работника в занимаемой должности

1) Увольнение сотрудника по ID своей ИС

PUT /api/v1/clients/:clientId/employees/:externalId/externalId/dismiss

или

• Увольнение сотрудника

PUT /api/v1/clients/:clientId/employees/:employeeId/dismiss

В случае если после увольнения у Физлица не остается действующих Сотрудников, то система HRlink блокирует для пользователя доступ в ЛК

Данная последовательность методов не является обязательным порядком.

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

• О том, как получить черновики - см. в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#2.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B8%D1%82%D1%8C-%D1%87%D0%B5%D1%80%D0%BD%D0%BE%D0%B2%D0%B8%D0%BA%D0%B8-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2

• Метод удаления документов не удаляет документы из системы безвозвратно, а помечает документ как удалённый.

2) Удаление роли

PUT /api/v1/clients/:clientId/employees/:employeeId/roles/remove

3) Кадровик получает реестр документов

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

4) Кадровик обновляет черновик документов для исключения увольняемого Сотрудника

PUT /api/v1/clients/:clientId/documentGroups

или

• Кадровик удаляет документы в которые входит увольняемый сотрудник

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

Сценарии работы Кадровика с Электронными подписями

Цель сценариев - Обеспечить сотрудника Электронной Подписью, соответствующей процессам Клиента, для выполнения КЭДО

Пользовательский Сценарий

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

Примечания

1. Кадровик подключает Пользователю ПЭП Госуслуги для работы с Документами/Заявлениями

Предусловие - Служба Внедрения включила применение ПЭП Госуслуги для ЮЛ Клиента, на основании запроса

1) Кадровик разрешает применение ПЭП Госуслуги для Пользователя

PUT api/v1/clients/:clientId/employees/:employeeId/signings/prr/enable

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

метод действует только по идентификатору Сотрудника в HRlink

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

• Т.е. если, к примеру, у Пользователя есть три сотрудника, то при включении права подписи одному из Сотрудников, включает право подписи для всех Сотрудников.

Сотруднику получившему разрешение на применение ПЭП Госуслуги при первом подписании будет необходимо авторизоваться через ЕСИА

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

Предусловие - для вызова метода запрета нужны идентификаторы Сотрудников. СМ. получение данных сотрудников.

1) Запрет ПЭП Госуслуги

PUT api/v1/clients/:clientId/employees/:employeeId/signings/prr/disable

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

метод действует только по идентификатору Сотрудника в HRlink

3. Кадровик выпускает Пользователю УНЭП для подписания

Предусловие - Пользователь - создан, данные ФЛ (паспорт) переданы

1) Кадровик создает заявку на выпуск УНЭП

POST api/v1/clients/:clientId/users/issue/nqes

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

Пример метода можно посмотреть - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#4.-%D0%92%D1%8B%D0%BF%D1%83%D1%81%D0%BA-%D0%A3%D0%9D%D0%AD%D0%9F

2) Получение полного списка справочника сотрудников

GET /api/v1/clients/:clientId/employees

или

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

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

или

• Получение данных сотрудника

GET /api/v1/clients/:clientId/employees/:employeeId

в поле lastNQESIssueRequest можно получить информацию о состоянии заявки на УНЭП

В случае отклонения заявки Сотрудником, Кадровик получит уведомление

Подробности см. в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#2.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%9F%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8F-%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. Кадровик разрешает пользователю подписание УНЭП Госключ

Предусловие - разрешение происходит только по идентификатору Пользователя в системе HRL, поэтому необходимо, чтобы у Кадровика был данный идентификатор. Можно получить:

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

GET /api/v1/clients/:clientId/employees

метод получения данных сотрудника по ID своей системы

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

метод получения данных физлица по номеру СНИЛС

GET /api/v1/clients/:clientId/users/:snils/snils

1) Кадровик разрешает применение УНЭП Госключ для Пользователя

PUT /api/v1/clients/:clientId/employees/:employeeId/signings/govkey/enable

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

метод действует только по идентификатору Сотрудника в HRlink

Сотруднику получившему разрешение на применение ПЭП Госуслуги при первом подписании будет необходимо авторизоваться через ЕСИА

Формирование Кадрового Документооборота

Сценарии Кадровика по Инициированию КЭДО

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

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

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

Примечания

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

1) Кадровик загружает файла(ы) для документа(ов)

POST /api/v1/files

Поле, в котором передается файл, может иметь любое имя.

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

При создании документа система конвертирует полученный файл в pdf/a. Конвертация файла является асинхронным процессом!

2) Кадровик получает список доступных типов документов

GET /api/v1/permittedDocumentTypes

Использование данного шага как части сценария позволит получить актуальный список типов документов для Кадровика

3) Кадровик создает черновик документа

POST /api/v1/clients/:clientId/documentGroups

При создании можно задавать Внешний ID (externalId), соответствующий идентификатору документа в вашей ИС. В HRlink Внешний ID (externalId) хранится как строка, поэтому допустимы любые строковые символы. Ограничения на максимальную длину строки нет.

4) Кадровик инициирует проверку на возможность отправки на подписание

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

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#6.-%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%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%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F

5) Кадровик отправляет документ на подписание

PUT /api/v2/clients/:clientId/documents/sendToSigning

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#7.-%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D0%BA-%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B

2. Кадровик подписывает Черновик (как руководитель) и отправляет дальше на подписание

Предусловие - Документ был создан (например, выполнены шаги 1-3 сценария 1)

1) Кадровик инициирует проверку документов на возможность подписания и отправки на подписание

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

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#6.-%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%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%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F

2) Кадровик запрашивает файл, который подписывается в HRlink

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

Необходимо получить файл, который был получен в HRlink после конвертации переданного файла в формат pdf/a.

Подписание УКЭПом должно производиться именно относительно файла, полученного в данном методе

3) Кадровик подписывает УКЭП (как руководитель) и отправляет документ дальше

PUT /api/v1/clients/:clientId/documents/sendAndSign

Само подписание УКЭПом производится за рамками HRlink, в данном методе только передаётся файл подписи

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#7.-%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D0%BA-%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B

3. Кадровик создает документ с отправкой на подписание при создании

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

POST /api/v1/files

1) Кадровик использует метод отправки документа на подписание при создании

POST /api/v1/clients/:clientId/documentGroups/sendToSigning

2) Кадровик запрашивает массив документов с заданными фильтрами

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

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

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

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

4. Кадровик отправляет на подписание ранее созданный черновик

Предусловие - черновик документа создан

1) Кадровик инициирует проверку на возможность отправки на подписание

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

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#6.-%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%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%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F

2) Кадровик отправляет черновик документа на подписание

PUT /api/v2/clients/:clientId/documents/sendToSigning

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#7.-%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D0%BA-%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B

Контроль Процесса Подписания

Сценарии Кадровика по работе с уже созданными документами

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

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

Примечания

1. Кадровик получает данные по документам, в том числе файлы по конкретному документу

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

1) Кадровик запрашивает список документов с учётом фильтров

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

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

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

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

2) Кадровик запрашивает документ по ID своей ИС

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

или

• Кадровик запрашивает документ по ID HRL

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

3) Кадровик получает печатную форму документа с оттисками

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

или

• Кадровик запрашивает файл, который подписывается в HRlink

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

Оригинальный файл, который был загружен не выгружается по API-методам и не входит в состав Архива КЭДО, поэтому при необходимости получения оригинального файла необходим запрос в службу поддержки

На момент составления описания метод получения ПФ документа не оформлен в API-документации

2. Кадровик редактирует параметры черновика

Предусловие - документ создан, но не был отправлен

Цель - внести изменения в метаданные документа:

• тип, номер, дата

• актуализировать состав участников

1) Кадровик вносит исправления в данные черновика документа

PUT /api/v1/clients/:clientId/documentGroups

Обновление происходит только внутри группы документов

2) используется один из описанных сценариев инициирования КЭДО

3. Кадровик заменяет Черновик

4. Кадровик заменят документ, находящийся на подписании

Цель - заменить файл документа или внести исправления в документ находящийся на подписании

1) Кадровик удаляет документ по ID документа в HRL

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

или

• Кадровик удаляет список документов по ID своей ИС или ID в HRL

DELETE /api/v1/clients/:clientId/documents

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

2) Кадровик затирает ID своей ИС в удаленном документе

PUT /api/v1/clients/:clientId/documents/:externalId/externalId/clearExternalId

3) Используется один из подходящих сценариев инициирования КЭДО

5. Кадровик выгружает архив КЭДО

Цель - реализовать выгрузку архивов КЭДО

• для бекапирования

• для наполнения своей ИС архивами

1) Кадровик получает список документов с соответствии с фильтрами

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

Данный шаг нужен для того, чтобы получить список документов, по которым требуется выгрузка архивов, однако если при создании документов используются идентификаторы своей системы, и список документов полностью управляется на стороне ИС Клиента, то данный шаг можно пропустить

2) Кадровик скачивает архив КЭДО по ID документа своей ИС

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

или

• Кадровик скачивает архив КЭДО по ID документа HRL

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

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

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

Архив КЭДО содержит в себе:

• сконвертированный файл

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

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

6. Кадровик инициирует повторное уведомления для подписантов

Цель - побудить участника КЭДО к подписанию

1) Кадровик получает список документов с соответствии с фильтрами

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

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

2) Кадровик инициирует повторное уведомление по документу

POST /api/v1/clients/:clientId/documents/signers/next/notify

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

Кадровому работнику не требуется определять на ком “зависло” подписание, система сама направляет уведомление текущему подписанту, с учётом того, какой канал уведомления является актуальным для Подписанта.

7. Кадровик добавляет заметку к документу

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

• Кадровик добавляет текст заметки к документу

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

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

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

Обработка Заявлений

1. Сценарии работы Кадровика с Шаблонами заявлений

Сценарий

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

Примечания

1. Кадровый работник обновляет файл шаблона действующего заявления

Предусловия

1. шаблон заявления создан через службу поддержки

2. есть идентификатор шаблона заявления

   1. список Шаблонов Заявлений

   2. GET /api/v1/applicationTypes

3. есть список системных полей (единый для всех шаблонов заявлений), которые можно использовать для настройки файла шаблона (подставлять в необходимые места шаблона)

   1. список системных полей

   2. GET /api/v1/applicationTypeFields/system

Цель - актуализировать файл шаблона

• общий файл

• файл шаблона для конкретного ЮЛ

1) Получение файла шаблона заявления

GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile

2) Кадровик загружает заранее подготовленный файл шаблона Заявления

POST /api/v1/files

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

Для каждого ЮЛ может быть свой файл шаблона заявления (см. схему)

3) Кадровик заменяет идентификатор файла на новый шаблон

PUT /api/v1/applicationTypes/:applicationTypeId

Данный метод позволяет:

1. Загрузить новый файл шаблона заявления

2. Активировать/Деактивировать шаблон заявления

3. Обновить состав пользовательских полей в шаблоне

4. Обновить имя шаблона

2. Кадровик обновляет параметры загруженного Шаблона Заявления

Предусловие - есть идентификатор шаблона заявления

• список Шаблонов Заявлений

  • GET /api/v1/applicationTypes

Цель - актуализировать информацию в шаблоне заявления:

• сделать шаблон видимым/скрытым для сотрудников

• обновить имя шаблона

• Кадровик обновляет доступные в шаблоне заявления данные

PUT /api/v1/applicationTypes/:applicationTypeId

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

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

API-метод

Примечания

1. Кадровик получает реестр Заявлений по конкретному заявителю/согласующему

Предусловие - в системе Клиента нет идентификатора Сотрудника HRL и используются только идентификаторы своей системы

1) Кадровик получает данные сотрудника по ID в своей ИС

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

Идентификатор Сотрудника в HRL смотрим в employee -> legalEntities -> employeeId

или

Кадровик получает данные ФЛ по СНИЛС

GET /api/v1/clients/:clientId/users/:snils/snils

Цель данного шага - получить идентификатор сотрудника в системе HRL, по которому требуется получить список заявлений, как по:

• Заявителю

• Согласующему

В случае, если в системе Клиента хранится связка идентификаторов Сотрудника HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить

2) Кадровик получает список Заявлений

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

Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9

2. Кадровик получает реестр Заявлений по отделу Заявителя

Предусловие - в системе Клиента нет идентификатора Отдела HRL и используются только идентификаторы своей системы

1) Кадровик получает справочник отделов

GET /api/v1/clients/:clientId/departments

Идентификатор Сотрудника в HRL смотрим в clientDepartments -> id

Цель данного шага - получить идентификатор отдела в HRL

В случае, если в системе Клиента хранится связка идентификаторов Отдела HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить

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

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

Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9

3. Кадровик получает реестр Заявлений по конкретному ЮЛ

Предусловие - в системе Клиента нет идентификатора Отдела HRL и используются только идентификаторы своей системы

1) Кадровик получает справочник Юрлиц

GET /api/v1/clients/:clientId/legalEntities

Идентификатор Юрлица в HRL смотрим в legalEntities -> id

Цель данного шага - получить идентификатор отдела в HRL

В случае, если в системе Клиента хранится связка идентификаторов Юрица HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить

2) Кадровик получает список Заявлений по Юрлицам

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

Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9

4. Кадровик получает все данные по Заявлениям с учётом всех фильтров

Цель - получить список заявлений по произвольному набору фильтров

• Кадровик получает список Заявлений в соответствии с фильтрами

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

Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9

5. Кадровик получает данные конкретного заявления (метаданные, файлы и архив)

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

1) Кадровик получает данные заявления по ID в HRL

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

На метаданные заявления содержат в себе:

• Данные Заявителя и Согласующего

• Данные Заявления: Группа, Дата, Номер

2) Кадровик получает:

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

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

• файл, который подписан

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

• архив КЭДО

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

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

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

На данный момент метод получения, подписываемого файла заявления, не оформлен в API-документации

6. Кадровик обрабатывает Заявление

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

• кадровик получает реестр заявлений, ожидающих обработки Кадровиком

1) Кадровик берёт заявление в работу

PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/claim

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

2) Кадровик принимает решение по заявлению:

• Заявление обработано Кадровиком

PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/process

• Заявление отклонено Кадровиком

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

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