Excerpt

Info

title	О чём раздел

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

Добавление новых Сотрудников
Обновление данных Сотрудника
1. Изменение данных Физлица
2. Кадровый перевод Сотрудника (из юрлица в юрлицо)
3. Изменение должности/отдела Сотрудника
4. Управление ролью Руководитель
Увольнение и Восстановление Сотрудника
Управление электронными подписями Сотрудника
Получение списка Сотрудников
1. Общий список
2. Список по фильтрам
3. Список в виде XLS файла

Table of Contents

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

Примечание

Info

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

Более подробно об объектах Физлицо и Пользователь можно ознакомиться в разделе → [03. Объекты и связи]

Функционал для пользователя определяется:

ролью (Администратор, Кадровик, Сотрудник, Руководитель)
доступными видами ЭП (УКЭП, УНЭП, ПЭП Госуслуги)
Данными Сотрудника
- ЮЛ, в котором оформлено ФЛ
- Отдел, к которому относится Сотрудник
- Должность, которую занимает Сотрудник

Управление справочниками описано в разделе → [01. Кадровик. Вспомогательные процессы: Управление структурой и Справочниками]

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

Tip

title	Цель сценария

В ЛК HRL приглашены Пользователи Клиента, которые смогут воспользоваться КЭДО после подтверждения учётной записи.

Note

title	Предусловие

Администратор выгрузил справочник юрлиц → [01. Администратор. Базовые настройки справочников]

YellowGdocYellowGdocYellowGdocYellowGdocYellowGdocYellowGdocYellowGdocYellowGdocКадровик приглашает конкретного сотрудника

или

YellowGdoc:clientUserIdinvite YellowGdoc

или

Кадровик приглашает конкретного сотрудника

POST /api/v1/clients/:clientId/users/:clientUserId/invite

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

1

API-методы

Примечания

1

1) Кадровик создает Физ.лицо, для которого будут созданы записи сотрудников

Status

colour
subtle	true

title
Green

redoc

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

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

1.1) Создать новую задачу массовой синхронизации данных

Status

subtle	true
colour	Green
title	redoc

POST /api/v1/clients/:clientId/bulkDataSyncTasks

1.2) Получить статус задачи массовой синхронизации данных по идентификатору задачи

Status

subtle	true
colour	Green
title	redoc

GET /api/v1/clients/:clientId/bulkDataSyncTasks/:taskId

Детализация пакетного метода - [4. (МС) Справочник пользователей и сотрудников]

В HRlin Пользователь представлен двумя объектами:

Физическое Лицо
1. Обладает учётной записью
2. Обладает каналами коммуникации
Сотрудник
1. Привязан к Юрлицу (обязательно)
2. Привязан к Отделу
3. Привязан к Должности

Такая модель позволяет для одного Физического Лица задавать несколько Сотрудников. См схему логических связей

В ответ на создание будет возвращен идентификатор clientUserId , который необходим для приглашения.

Note

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

постановка задачи предполагает как создание только физлиц, так и создание физлица сразу с перечнем сотрудников.

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

2

2) Кадровик создает Сотрудника для существующего ФЛ

Status

colour
subtle	true

title
Green

redoc

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

Note
Если использован пакетный метод, то данный шаг можно пропустить.

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

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

3

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

Status

colour
subtle	true

title
Green

redoc

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

или

Получение постраничного справочника с фильтрацией
Status
subtle true
colour

Green
title

redoc

POST /api/v1/clients/:clientId/employees/getRegistry

Для получения данных по одному сотруднику можно использовать один из следующих вариантов:

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

Green
title

redoc

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

или

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

Green
title

redoc

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

или

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

Green
title

redoc

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

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

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

данные по физлицу будут возвращать в том числе данные по всем сотрудникам физлица.

4

4) Кадровик приглашает группу сотрудников

Status

colour
subtle	true

title
Green

redoc

POST /api/v1/clients/:clientId/users/invite

метод валидации перед приглашением

Status
subtle true
colour

Green
title

redoc

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

invitations/

validate

После того как ФЛ создано и ему добавлены и настроены записи Сотрудников, чтобы Работник мог воспользоваться ЛК, ему требуется направить приглашение. В группе может быть 1 и более сотрудник.

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

Работник получив приглашение подтвердит свою учётную запись и только после этого сможет использовать ЛК в рамках Кадрового Электронного Документооборота

Note
При приглашении можно задать какие электронные подписи должны быть доступны Сотруднику. Это позволит будет пропустить сценарии с выпуском электронной подписи.

5

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

Status

colour
subtle	true

title
Green

redoc

POST /api/v1/clients/:clientId/users/invite

Status

subtle

true

colour

Yellow

title

Gdoc

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

Note

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

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

Tip

title	Цель сценария

Обеспечить отправку приглашения Сотруднику на другой канал уведомления.

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

YellowGdocYellowGdocYellowGdoc

или

Кадровик приглашает конкретного сотрудника

POST /api/v1/clients/:clientId/users/:clientUserId/invite

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

Примечания

1

1) Кадровик отменяет неподтверждённое приглашение

Status

colour
subtle	true

title
Green

redoc

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

2

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

Status

colour
subtle	true

title
Green

redoc

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

или

Обновление физлица по ID HRL
Status
subtle true
colour

Green
title

redoc

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

3

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

Status

colour
subtle	true

title
Green

redoc

POST /api/v1/clients/:clientId/users/invite

Status

subtle

true

colour

Yellow

title

Gdoc

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

Tip

title	Цель сценария

Кадровик

Tip

title	Цель сценария

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

Note

title	Предусловие

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

Получение список ролей сотрудников Status
subtle true
colour
Yellow
Green
title
Gdoc
redoc

GET /api/v1/employeeRoles

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

Получение постраничного справочника с фильтрацией
Status
subtle true
colour
Yellow
Green
title
Gdoc
redoc
POST /api/v1/clients/:clientId/employees/getRegistry

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

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

YellowGdocemployees

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

Примечания

1

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

Status

colour
subtle	true

title
Green

redoc

POST /api/v1/clients/:clientId/

employees

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

YellowGdocPUT v1employeesexternalId/externalId YellowGdocv1

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

Примечания

1

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

Status

colour
subtle	true

title
Green

redoc

PUT /api/

v3/clients/:clientId/

employeesByExternalId/:

employeeExternalId

или

Кадровик обновляет сотрудника по ID HRL
Status
subtle true
colour

Green
title

redoc

PUT /api/

v3/clients/:clientId/employees/:employeeId

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

RedaddonRedaddon

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

Примечания

1

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

Status

colour
subtle	true

title
Green

redoc

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

или

Удаление роли
Status
subtle true
colour

Green
title

redoc

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

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

Expand

title	Пояснения к методу добавления роли

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

Тело запроса

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

Ответ

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

Expand

title	Пояснения к методу удаления роли

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

Тело запроса

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

Ответ

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

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

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

Tip

title	Цель сценария

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

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

Tip

title	Цель сценария

Кадровая система HRlink обогащает данными ИС Клиента:

готовность учётной записи сотрудника
наличие и состояние ЭП у сотрудника

Также при изменении данных в ИС Клиента, необходимо корректно эти изменения передавать в HRlink:

обновление данных ФЛ
обновление данных сотрудника
кадровый перевод (из одного юрлица в другое)
увольнение сотрудника

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

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

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

Примечания

1

1) Получение постраничного справочника с фильтрацией

Status

subtle	true
colour	Green
title	redoc

POST /api/v1/clients/:clientId/employees/getRegistry

или

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

GET

Кадровая система HRlink обогащает данными ИС Клиента:

готовность учётной записи сотрудника
наличие и состояние ЭП у сотрудника

Также при изменении данных в ИС Клиента, необходимо корректно эти изменения передавать в HRlink:

обновление данных ФЛ
обновление данных сотрудника
кадровый перевод (из одного юрлица в другое)
увольнение сотрудника

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

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

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

Примечания

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

/api/v1/clients/:clientId/

employees/getRegistry

users/:snils/snils

или

Получение данных

физлица по номеру СНИЛС

сотрудника по ID своей ИС Status
subtle true
colour

Yellow

Green
title

Gdoc

redoc

GET /api/v1/clients/:clientId/

users

employees/:

snils

externalId/

snils

externalId

или

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

своей ИС

HRL Status
subtle true
colour

Yellow StatussubtletruecolourYellowtitleGdoc

Green
title

Gdoc

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

или

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

redoc

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

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

Expand

title	Понять состояние учётной записи

На примере метода (фильтрационные параметры можно посмотреть в документации)

POST /api/v1/clients/:clientId/employees/getRegistry

Тело Ответа

Markdown

```
{
    "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
		},
		...
}
```

данные возвращаются по сотрудникам, если у ФЛ несколько Сотрудников, то будет несколько объектов в списке.

employees[].invitation - если пусто, то значит, что пользователю ещё не направлялось приглашение
- employees[].invitation.type - куда отправлялось приглашение
- employees[].invitation.invitationCreatedDate - когда отправлялось приглашение
disabledDate - если пользователь заблокирован, то будет дата, иначе - null
dismissedDate - дата увольнения, если Сотрудник уже уволен, то будет дата, иначе - null
scheduledDismissDate - дата запланированного увольнения, если запланировано увольнение, то будет дата, иначе - null
employees[].notificationChannels - список каналов уведомления, если список пустой, значит пользователю не были заданы каналы уведомления
- подтверждённые каналы уведомления также являются логинами для входа, но активным может быть только один канал уведомления
- employees[].notificationChannels[].type - тип канала уведомления
- employees[].notificationChannels[].confirmed - канал подтверждён (true) или нет (false)
- employees[].notificationChannels[].invited - было ли отправлено на данный канал уведомления приглашение - да (true) или нет (false)

Expand

title	Понять состояние электронной подписи

На примере метода (фильтрационные параметры можно посмотреть в документации )

POST /api/v1/clients/:clientId/employees/getRegistry

Тело Ответа

Markdown

```
{
    "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
		},
		...
}
```

данные возвращаются по сотрудникам, если у ФЛ несколько Сотрудников, то будет несколько объектов в списке.

employees[].prrSigningEnabled - право подписания через Портал Работа в России
employees[].govKeySigningEnabled - право подписания через МП Госключ
employees[].qesSigningEnabled - право подписания УКЭП
employees[].lastNqesIssueRequest - последний запрос на выпуск УНЭП, если запрос не создавался, то будет null
- employees[].lastNqesIssueRequest.state - состояние запроса на выпуск УНЭП

employees[].lastNqesIssueRequest.createdDate - дата когда был создан запрос на выпуск УНЭП

employees[].lastNqesIssueRequest.applicationCreatedDate - дата формирования заявки на выпуск УНЭП

employees[].lastNqesIssueRequest.userNotifiedAboutIssueRequestDate - дата отправки сотруднику уведомления о необходимости подтверждения заявки на УНЭП

employees[].lastNqesIssueRequest.issuingConfirmedDate - дата подтверждения заявки сотрудником

employees[].lastNqesIssueRequest.issuingRejectedDate - дата отклонения заявки сотрудником

employees[].lastNqesIssueRequest.userNotifiedAboutCertificateDate - дата отправки сотруднику уведомления о необходимости подтверждения Сертификата УНЭП (сертификат формирует УЦ)

employees[].lastNqesIssueRequest.certificateAcceptedDate - дата подтверждения Сертификата сотрудником

employees[].lastNqesIssueRequest.certificateDeclinedDate - дата отклонения Сертификата сотрудником

employees[].lastNqesIssueRequest.finishedDate - дата завершения процесса выпуска УНЭП

employees[].certificates - список сертификатов УНЭП, если список пустой, то у Пользователя нет сертификатов УНЭП

employees[].certificates[].type - тип сертификата
employees[].certificates[].personIdentificationType - способ идентификации
employees[].certificates[].validAfterDate - дата начала действия сертификата
employees[].certificates[].expiresDate - дата завершения срока действия сертификата

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

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

- - CREATED - Задача процесса выпуска НЭП через ПЭП создана.
  - APPLICATION_CREATION_PENDING -Запущен процесс изготовления файла заявления выпуска НЭП.
  - APPLICATION_CREATED- Файл заявления выпуска НЭП изготовлен.
  - USER_NOTIFIED_ABOUT_ISSUE_REQUEST - Пользователь уведомлён о том, что ему хотят выпустить НЭП.
  - ISSUING_CONFIRMED - Пользователь подтвердил выпуск НЭП.
  - ISSUING_REJECTED - Пользователь отклонил выпуск НЭП. (Терминальное состояние)
  - PERSON_IDENTIFICATION_CREATED - Создана задача удаленной идентификации человека.
  - PERSON_IDENTIFICATION_FAILED - Задача удаленной идентификации человека завершилась с ошибкой. (Терминальное состояние)
  - PERSON_IDENTIFIED- Задача удаленной идентификации человека завершилась успешно.
  - PRINT_FORM_CREATION_PENDING- Запущен процесс изготовления печатной формы заявления с оттиском ПЭП.
  - PRINT_FORM_CREATED - Печатная форма заявления с оттиском ПЭП изготовлена.
  - NQES_ISSUE_REQUEST_CREATED - Заявка на выпуск НЭП создана.
  - NQES_ISSUE_REQUEST_FAILED Заявка на выпуск НЭП завершилась с ошибкой. (Терминальное состояние)
  - NQES_ISSUED - НЭП выпущен.
  - USER_NOTIFIED_ABOUT_CERTIFICATE - Пользователь уведомлён о том, что НЭП выпущен.
  - CERTIFICATE_ACCEPTED - Пользователь подтвердил данные в выпущенном сертификате.
  - CERTIFICATE_DECLINED - Пользователь отклонил данные в выпущенном сертификате. (Терминальное состояние)
  - FINISHED - Процесс выпуска НЭП через ПЭП завершён. (Терминальное состояние)
  - CANCELED - Процесс выпуска НЭП через ПЭП отменён. (Терминальное состояние)
- employees[].lastNqesIssueRequest.createdDate - дата когда был создан запрос на выпуск УНЭП
- employees[].lastNqesIssueRequest.applicationCreatedDate - дата формирования заявки на выпуск УНЭП
- employees[].lastNqesIssueRequest.userNotifiedAboutIssueRequestDate - дата отправки сотруднику уведомления о необходимости подтверждения заявки на УНЭП
- employees[].lastNqesIssueRequest.issuingConfirmedDate - дата подтверждения заявки сотрудником
  - employees[].lastNqesIssueRequest.issuingRejectedDate - дата отклонения заявки сотрудником
- employees[].lastNqesIssueRequest.userNotifiedAboutCertificateDate - дата отправки сотруднику уведомления о необходимости подтверждения Сертификата УНЭП (сертификат формирует УЦ)
- employees[].lastNqesIssueRequest.certificateAcceptedDate - дата подтверждения Сертификата сотрудником
  - employees[].lastNqesIssueRequest.certificateDeclinedDate - дата отклонения Сертификата сотрудником
- employees[].lastNqesIssueRequest.finishedDate - дата завершения процесса выпуска УНЭП
employees[].certificates - список сертификатов УНЭП, если список пустой, то у Пользователя нет сертификатов УНЭП
- employees[].certificates[].type - тип сертификата
- employees[].certificates[].personIdentificationType - способ идентификации
- employees[].certificates[].validAfterDate - дата начала действия сертификата
- employees[].certificates[].expiresDate - дата завершения срока действия сертификата

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

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

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

Примечания

1

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

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

или

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

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

Примечания

1

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

Status

subtle	true
colour	Green
title	redoc

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

паспорт

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

clientUserId

externalId/externalId

или

Обновление физлица по ID HRL Status
subtle true
colour Green
title redoc

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

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

паспорт

снилс
инн
фио

2

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

Status

subtle	true
colour	Green
title	redoc

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

или

Удаление канала уведомления сотрудника
Status
subtle true
colour Green
title redoc

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

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

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

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

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

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

.

Все подтверждённые каналы уведомления также являются логинами для авторизации.

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

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

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

	Действия и API-методы	Примечания

2.

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

Физлица

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

ФИО
Паспортные данные и данные документов (СНИЛС, ИНН)
Данные для Уведомления и Авторизации, в т.ч. удаление канала уведомления

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

сотрудника по ID своей ИС

Status

subtle	true
colour	Green
title	redoc

PUT /api/

v1

v4/clients/

:

или

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

{clientId}/

users/:externalId/externalId

employeesByExternalId/{employeeExternalId}

или

Кадровик обновляет данные одного сотрудника
Status
subtle true
colour Green
title redoc

PUT /api/

v1

v3/clients/:clientId/

users

employees/:

clientUserId

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

паспорт
снилс
инн
фио

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

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

или

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

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

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

employeeId

Обновление сотрудника позволяет актуализировать такие данных как:

Отдел
Должность
Роль - Сотрудник или Руководитель см. [Вариант 2. Кадровик при обновлении сотрудника назначает роль Руководитель]
табельный номер - через параметр "number"
externalId Сотрудника
теги сотрудника
дни отпуска - через параметр "availableVacationDayCount"

уволить сотрудника через метод обновления - нельзя.

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

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

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

Примечания

1

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

Status

subtle	true
colour	Green
title	redoc

PUT

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

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

Отдел
ЮЛ
Должность
Роль - Сотрудник или Руководитель

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

PUT

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

или

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

Увольнение сотрудника
Status
subtle true
colour Green
title redoc

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

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

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

/dismiss

Метод увольнения позволяет передать и будущую дату увольнения.

2

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

Status

subtle	true
colour	Green
title	redoc

PUT

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

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

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

employees/:employeeId/roles/remove

Увольнение сотрудника с ролью Кадровик не приводит к снятию роли Кадровик, поэтому рекомендуется удалять роль у Сотрудников, которые имеют роль Кадровик.

Expand

title	Пояснения к методу удаления роли

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

Тело запроса

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

Ответ

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

3

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

Status


subtle	true
colour	Yellow
title	Gdoc

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

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

Status


subtle	true
colour	Yellow
title	Gdoc

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

или

Кадровик удаляет документы в которые входит увольняемый сотрудник
Status
subtle true
colour Yellow
title Gdoc

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

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

удалить уволенного сотрудника из черновика документа
удалить (через отметку об удалении) все документы, которые "зависли" на уволенном сотруднике

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

Note

title	Предусловие

Сотрудник уволен и у пользователя заблокирована учётная запись

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

Примечания

1

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

Status


subtle	true
colour	Red
title	addon

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

или

Кадровик восстанавливает сотрудника по идентификатору ИС Клиента

Status


subtle	true
colour	Red
title	addon

PUT /api/v1/clients/:clientId/employeesByExternalId/:employeeExternalId/restore

Expand

title	Пояснения к методу Восстановления сотрудника

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

Тело запроса

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

Валидации:

Валидация восстановления сотрудника по ID HR-Link
1. ID сотрудника соответствует формату UUID. (13.005)
2. Сотрудник с заданным ID существует (13.457)
3. ID клиента соответствует формату UUID (13.005)
4. Клиент существует по заданному ID (13.005)
5. Заданный пользователь относится к заданному клиенту (13.101)
6. Сотрудник с заданным ID уволен (заполненое поле dissmised_date), либо существует активная задача на отложенного увольнения (13.466)
7. Сотрудник относится к заданному клиенту (13.453)
8. У пользователя клиента есть право (на уровне сотрудника или пользователя клиента EMPLOYEES_RESTORE) на восстановление сотрудника на уровне пользователя клиента или на уровне сотрудника клиента в юр.лице восстанавливаемого сотрудника (10.000)
9. Наличие у пользователя клиента прав на действия с сотрудником на уровне отдела сотрудника (13.750)
10. Тело запроса задано (10.006)
11. Если тело запроса с версией пришло, то указана корректная версия сотрудника (13.452)
Валидации восстановление сотрудника по внешнему ID
1. ID клиента соответствует формату UUID (13.005)
2. Сотрудник с заданным внешним ID существует у клиента (13.454, 13.451)
3. Клиент существует по заданному ID (13.005)
4. Заданный пользователь относится к заданному клиенту (13.101)
5. Сотрудник с заданным ID уволен (заполненое поле dissmised_date), либо существует активная задача на отложенного увольнения (13.466)
6. Сотрудник относится к заданному клиенту (13.453)
7. У пользователя клиента есть право (на уровне сотрудника или пользователя клиента EMPLOYEES_RESTORE) на восстановление сотрудника на уровне пользователя клиента или на уровне сотрудника клиента в юр.лице восстанавливаемого сотрудника (10.000)
8. Наличие у пользователя клиента прав на действия с сотрудником на уровне отдела сотрудника (13.750)
9. Тело запроса задано (10.006)
10. Если тело запроса с версией пришло, то указана корректная версия сотрудника (13.452)

Ответ

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

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

Note

title	Предусловие

Выполнена первичная передача данных по Сотрудникам из ИС Клиента в HRlink

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

Примечания

1

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

см. [Увольнение Сотрудника]

2

2) Создание Сотрудника на основании Физлица

Status


subtle	true
colour	Yellow
title	Gdoc

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

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

Выпуск УНЭП

Tip

title	Цель сценария

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

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

Примечания

1

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

Status


subtle	true
colour	Yellow
title	Gdoc

POST

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

Действия и 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/

employeesGET /

users/

:externalId/externalId

или

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

issue/nqes

Как понять состояние выпуска УНЭП см. [Определение состояния Учётной записи и наличия ЭП]

2

2) Смена канала подписания УНЭП

Status


subtle	true
colour	Red
title	addon

POST

api/v1/clients/:clientId/

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

users/:clientUserId/nqesChannelChangeRequests

В случае

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

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

Expand

title	Пояснения к методу смены канала подписания

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

Тело запроса

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

Ответ

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

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

Tip

title	Цель сценария

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

Note

title	Предусловие

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

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

Примечания

1

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

Status


subtle	true
colour	Red
title	addon

PUT

Подробности см. в разделе 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 своей системы

employees/:employeeId/signings/prr/enable

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

Status


subtle	true
colour	Red
title	addon

PUT

GET /1)

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

externalId/externalId

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

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

employeeId/signings/prr/disable

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

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

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

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

2

3)

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

Status


subtle	true
colour	Red
title	addon

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

enable

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

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

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

enable

Предыдущий раздел

01. Кадровик. Вспомогательные процессы: Управление структурой и Справочниками

Следующий раздел

03. Кадровик. Основные процессы: Формирование и контроль Документооборота

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

Livesearch

spaceKey	WIKI
size	large

Page tree

Page History

Versions Compared

Old Version 7

New Version Current

Key

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выпуск УНЭП

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

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

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

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

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

Предыдущий раздел

Следующий раздел