Versions Compared

Old Version 12

changes.mady.by.user Шелест Леонид

Saved on

compared with

New Version Current

changes.mady.by.user Пупарева Ксения

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt
Info
titleО чём раздел

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

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

Table of Contents

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

Примечание

Info

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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

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

1

API-методы

Примечания

1

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

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

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

Status
subtletrue
colourGreen
titleredoc

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

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

Status
subtletrue
colourGreen
titleredoc

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


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

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

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

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

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

  2. Сотрудник

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

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

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

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

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


Note

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

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


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

2

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

Note

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

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

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

3

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

 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) Кадровик приглашает группу сотрудников

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

или

Кадровик приглашает конкретного сотрудника Yellow
  • Green
    title
Gdoc
  • redoc

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

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

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

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

Note

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

5

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

или

Кадровик приглашает конкретного сотрудника
Status
subtletrue
colourYellow
titleGdoc
Note

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

Note

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


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

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


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


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


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

Примечания

1

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

Status
subtletrue
colourYellowGreen
titleGdocredoc

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


2

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

или

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


3

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

или

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

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



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

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


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


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

Note
title
Tip
titleЦель сценария
Note
titleПредусловие

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

 GET /api/v1/employeeRoles 

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

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

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


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

Примечания

1

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

POST /api/v1/clients/:clientId/employeesemployees 



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


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

Примечания

1

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

 PUT PUT /api/v1v3/clients/:clientId/employeesemployeesByExternalId/:externalId/externalId employeeExternalId 

или

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



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

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

Тело запроса


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

Примечания

1

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

Status
subtletrue
colourRedGreen
titleaddonredoc

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

или

 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Пояснения к методу удаления роли
Markdown
```
{
    "roleId": "fcaa233d-93c9-4545-a5b6-4ccd78b1a9b0"
}
```

Ответ

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

Сотрудника в HRlink


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

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

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


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

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

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

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


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

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

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


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

Примечания

1

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

Status
subtletrue
colour
Yellow
Green
title
Gdoc
redoc

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

или

Yellow
  • Green
    title
Gdoc
  • redoc

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

или

Yellow
  • Green
    title
Gdoc
  • redoc

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

или

Yellow
  • Green
    title
Gdoc
  • redoc

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


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

(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)

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

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

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

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

      • 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 своей системыИС

Status
subtletrue
colourYellowGreen
titleGdocredoc

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

или

Полное обновления Yellow
  • Green
    title
Gdoc
  • redoc

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

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

  • паспорт

  • снилс

  • инн

  • фио

2

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

Status
subtletrue
colourYellowGreen
titleGdocredoc

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

или

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

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

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

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


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

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

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


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

Примечания

1

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

Status
subtletrue
colourYellowGreen
titleGdocredoc

 PUT /api/v1v4/clients/:{clientId}/employees/:externalId/externalId employeesByExternalId/{employeeExternalId} 

или

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

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

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


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

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

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


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

Примечания

1

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

Status
subtletrue
colourYellowGreen
titleGdocredoc

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

или

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

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

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

Status
subtletrue
colour
Red
Green
title
addon
redoc

 PUT /api/v1/clients/:clientId/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
subtletrue
colourYellow
titleGdoc

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

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

Status
subtletrue
colourYellow
titleGdoc

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

или

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

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

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


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

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

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

Примечания

1

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

Status
subtletrue
colourRed
titleaddon

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

или

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

Status
subtletrue
colourRed
titleaddon

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
subtletrue
colourYellow
titleGdoc

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


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

Выпуск УНЭП

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


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



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

Примечания

1

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

Status
subtletrue
colourYellow
titleGdoc

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

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

2

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

Status
subtletrue
colourRed
titleaddon

 POST api/v1/clients/:clientId/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
subtletrue
colourRed
titleaddon

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

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

Status
subtletrue
colourRed
titleaddon

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

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

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

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

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

2

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

Status
subtletrue
colourRed
titleaddon

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


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

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

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

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

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

Livesearch
spaceKeyWIKI
sizelarge