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

Compare with Current View Page History

« Previous Version 8 Next »

О чём раздел

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

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

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

Примечание

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

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

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

  • ролью (Администратор, Кадровик, Сотрудник, Руководитель)

  • доступными видами ЭП (УКЭП, УНЭП, ПЭП Госуслуги)

  • Данными Сотрудника

    • ЮЛ, в котором оформлено ФЛ

    • Отдел, к которому относится Сотрудник

    • Должность, которую занимает Сотрудник

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


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

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


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


Предусловие

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

1

API-методы

Примечания

1

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

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

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

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

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

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

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

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

  1. Физическое Лицо

    1. Обладает учётной записью

    2. Обладает каналами коммуникации

  2. Сотрудник

    1. Привязан к Юрлицу (обязательно)

    2. Привязан к Отделу

    3. Привязан к Должности

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

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


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

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


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

2

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

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

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

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

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

3

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

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

или

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

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

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

или

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

или

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


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

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


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

4

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

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

или

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

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

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

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

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

5

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

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

или

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

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


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

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


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



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

Примечания

1

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

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

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

2

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

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

или

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


3

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

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

или

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



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

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


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


Предусловие

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

 GET /api/v1/employeeRoles 

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

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

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

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


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

Примечания

1

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

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



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


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

Примечания

1

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

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

или

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



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


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

Примечания

1

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

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

или

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

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

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

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

Тело запроса

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

Ответ

{
    "result": true
}

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

Тело запроса

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

Ответ

{
    "result": true
}


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

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

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


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

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

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

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


Предусловие

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

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


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

Примечания

1

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

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

или

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

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

или

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

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

или

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


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

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

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

Тело Ответа

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

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

  • employees[].invitation - если пусто, то значит, что пользователю ещё не направлялось приглашение
    • employees[].invitation.type - куда отправлялось приглашение
    • employees[].invitation.invitationCreatedDate - когда отправлялось приглашение

  • disabledDate - если пользователь заблокирован, то будет дата, иначе - null

  • dismissedDate - дата увольнения, если Сотрудник уже уволен, то будет дата, иначе - null

  • scheduledDismissDate - дата запланированного увольнения, если запланировано увольнение, то будет дата, иначе - null

  • employees[].notificationChannels - список каналов уведомления, если список пустой, значит пользователю не были заданы каналы уведомления
    • (warning) подтверждённые каналы уведомления также являются логинами для входа, но активным может быть только один канал уведомления
    • employees[].notificationChannels[].type - тип канала уведомления

    • employees[].notificationChannels[].confirmed - канал подтверждён (true) или нет (false)

    • employees[].notificationChannels[].invited - было ли отправлено на данный канал уведомления приглашение - да (true) или нет (false)

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

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

Тело Ответа

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

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

  • 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 - дата завершения срока действия сертификата

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

Предусловие

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


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

Примечания

1

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

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

или

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

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

  • паспорт

  • снилс

  • инн

  • фио

2

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

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

или

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

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


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


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


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


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

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

Примечания

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 блокирует для пользователя доступ в ЛК

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

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

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-документации see-no-evil monkey

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

Пример метода можно посмотреть - 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-документации see-no-evil monkey

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

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

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

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

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

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

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

  • No labels