| Excerpt | |||||
|---|---|---|---|---|---|
|
| Table of Contents |
|---|
1. Управление структурой
Основные сценарии управления структурой и Справочниками
Примечание
| Infotip | ||
|---|---|---|
| ||
В HRlink сохранены данные обо всех юрлицах клиента, составлен список отделов, который представлен в виде древовидной структуры (родительские и дочерние отделы) и определены все должности. |
| Note | ||
|---|---|---|
| ||
Создание Юрлиц производится Администратором → [01. Администратор. Базовые настройки справочников] |
API-методы
Примечания
POST /api/v1/clients/:clientId/departments
POST /api/v1/clients/:clientId/employeePositions
При создании можно указать Идентификатор Должности в ИС Клиента, через поле externalId, это позволит в дальнейшем использовать внутренний (с точки зрения Клиента) идентификатор для работы с должностями.
| |
В данном разделе указаны сценарии для Кадрового специалиста, однако, Администратор может выполнит всё, что может выполнить Кадровик. В ряде случае для Клиента наиболее простой путь интеграции (особенно если идёт интеграция только кадрового потока процессов, см. раздел [01. Подходы к интеграции]) - использование токена Администратора.
|
Обновление данных Юрлица
| Tip | ||
|---|---|---|
| ||
Актуализация информации о Юрлица клиента. В юрлице может быть задан руководитель имеющий право действовать без МЧД. Также данные данного руководителя (ФИО и Должность в дательном падеже) могут быть использованы для подстановки в шаблоны заявлений, если эти переменные указаны в файле шаблона заявления (на чьё имя подаётся заявление). |
| Note | ||
|---|---|---|
| ||
Администратор выгрузил справочник юрлиц → [01. Администратор. Базовые настройки справочников] |
2. Обновление данных Юрлица
| Tip | ||
|---|---|---|
| ||
актуализация информации о Юрлица клиента. |
| 1 |
|---|
API-методы | Примечания | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 1 |
GET /api/v1/clients/:clientId/legalEntities |
или
PUT /api/v1/clients/:clientId/legalEntities/:legalEntityExternalId/externalId | Данный шаг можно пропустить, т.к. |
он нужен только для получения списка идентификаторов, чтобы производить обновления по конкретному ЮЛ. Кроме получения данных всего списка можно получить данные одного Юрлица. | |||||||||
| 2 |
PUT /api/ |
v3/clients/:clientId/ |
legalEntitiesByExternalId/: |
legalEntityExternalId или |
|
PUT /api/ |
API-методы
Примечания
v3/clients/:clientId/legalEntities/:legalEntityId |
через поле externalId (Идентификатор ЮЛ в ИС Клиента)
3. Обновление данных Отдела
| Tip | ||
|---|---|---|
| ||
актуализация информации о действующих Отделах. |
| 3 | 1) Создать новую задачу массовой синхронизации данных POST |
/api/v1/clients/:clientId/ |
Данный шаг можно пропустить, т.к. он нужен только для получения списка идентификаторов, чтобы производить обновления по конкретному Отделу
bulkDataSyncTasks 2) Получить статус задачи массовой синхронизации данных по идентификатору задачи GET |
/api/v1/clients/:clientId/ |
bulkDataSyncTasks/: |
или
PUT api/v1/clients/:clientId/departments/:departmentId
или
DELETE /api/v1/clients/:clientId/departments/:departmentId
Удаление рассматривается как частный случай обновления.
При удалении отдел помечается как удалённый и более не доступен для выбора, но физически информация из базы данных не удаляется и все сотрудники и привязки документов к удалённым отделам - сохраняются.
4. Обновление данных Должностей
| Tip | ||
|---|---|---|
| ||
актуализация информации о действующих должностях. |
API-методы
Примечания
GET /api/v1/clients/:clientId/employeePositions
Данный шаг можно пропустить, т.к. он нужен только для получения списка идентификаторов, чтобы производить обновления по конкретной Должности
PUT /api/v1/clients/:clientId/employeePositions/:externalId/externalId
или
PUT /api/v1/clients/:clientId/employeePositions/:positionId
или
DELETE /api/v1/clients/:clientId/employeePositions/:positionId
Удаление рассматривается как частный случай обновления.
При удалении Должность помечается как удалённая и более не доступна для выбора, но физически информация из базы данных не удаляется и все данные по сотрудникам - сохраняются.
5. Организация справочника Типы Документов
| Tip | ||
|---|---|---|
| ||
подготовить справочник Типов Документов для КЭДО. |
API-методы
Примечания
GET /api/v1/documentTypes
При создании Клиента, HR-link передает базовый список типов документов, с которых уже можно начинать работу. Поэтому чтобы не создавать дублирующие типы заявлений может быть полезным сперва изучить заданные типы документов.
POST /api/v1/documentTypes
При создании можно указать Идентификатор Типа Документа в ИС Клиента, через поле externalId, это позволит в дальнейшем использовать внутренний (с точки зрения Клиента) идентификатор для работы с документами.
PUT /api/v1/documentTypes/:externalId/externalId
PUT /api/v1/documentTypes/:documentTypeId
6. Организация справочника Шаблонов Заявлений
| Tip | ||
|---|---|---|
| ||
подготовка справочника Шаблонов Заявлений, которыми сможет воспользоваться Сотрудник при подаче Заявлений. К подготовке можно отнести актуализацию - корректировку имён шаблонов и видимость для Сотрудника при подаче |
| Note | ||
|---|---|---|
| ||
Первичное создание шаблона заявления сейчас доступно только через обращение в Службу Заботы о Клиентах, дальнейшее использование и настройка - доступны как в ЛК, так и по API Подробнее о заявлениях см. раздел Заявление |
API-методы
Примечания
GET /api/v1/applicationTypes
Для того, чтобы Сотрудник мог подавать заявления из шаблона, требуется настроить шаблоны.
GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile
Шаблонный файл может быть доработан Клиентом в плане содержания статического текста и размещения доступных переменных, значения которых будут использоваться при генерации заявления из шаблона.
Клиент так же может задать собственное форматирование файла - шрифты, кегель, отступы и т.д.
Оформление шаблона происходит вне рамок информационных систем.
GET /api/v1/applicationTypeFields/system
Системные поля необходимы для того, чтобы можно было настроить свой собственный шаблон заявления
POST /api/v1/files
Поле, в котором передается файл, может иметь любое имя.
В одном запросе можно передать один или несколько файлов. В случае отправки нескольких файлов следует давать полям разные имена.
Для Каждого ЮЛ на один тип Заявления может быть задан собственный шаблон.
PUT /api/v1/applicationTypes/:applicationTypeId
При обновлении Кадровик
задаёт названия Шаблонов, используемых Клиентом,
привязывает идентификатор обновлённого шаблонного файла
задает видимость
7. Получение списка доверенностей, получение данных доверенности
| Tip | ||
|---|---|---|
| ||
... |
| Note | ||
|---|---|---|
| ||
... |
API-методы
Примечания
GET /api/v1/applicationTypes
Для того, чтобы Сотрудник мог подавать заявления из шаблона, требуется настроить шаблоны.
GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile
Шаблонный файл может быть доработан Клиентом в плане содержания статического текста и размещения доступных переменных, значения которых будут использоваться при генерации заявления из шаблона.
Клиент так же может задать собственное форматирование файла - шрифты, кегель, отступы и т.д.
Оформление шаблона происходит вне рамок информационных систем.
GET /api/v1/applicationTypeFields/system
Системные поля необходимы для того, чтобы можно было настроить свой собственный шаблон заявления
POST /api/v1/files
Поле, в котором передается файл, может иметь любое имя.
В одном запросе можно передать один или несколько файлов. В случае отправки нескольких файлов следует давать полям разные имена.
Для Каждого ЮЛ на один тип Заявления может быть задан собственный шаблон.
PUT /api/v1/applicationTypes/:applicationTypeId
При обновлении Кадровик
задаёт названия Шаблонов, используемых Клиентом,
привязывает идентификатор обновлённого шаблонного файла
задает видимость
Управление Персоналом
| Info |
|---|
Пользователем системы HRlink является Физическое Лицо, которое выступает в качестве Сотрудника Компании, в рамках КЭДО. Функционал для пользователя определяется:
Управление справочниками описано в разделе - Управление Структурой |
Пользовательский Сценарий
Действия и API-методы
Примечания
1. Кадровик создаёт учётные записи пользователей и приглашает к подтверждению
Цель - В ЛК HRL приглашены Пользователи Клиента, которые смогут воспользоваться КЭДО после подтверждения учётной записи.
1) Кадровик создает Физ.лицо, для которого будут созданы записи сотрудников
POST /api/v1/clients/:clientId/users
В HRlin Ползователь представлен двумя объектами:
Физическое Лицо
Обладает учётной записью
Обладает каналами коммуникации
Сотрудник
Привязан к Юр.лицу
Привязан к Отделу
Привязан к Должности
Такая модель позволяет для одного Физического Лица задавать несколько Сотрудников. См схему логических связей
В ответ на создание будет возвращен идентификатор clientUserId, который необходим для приглашения.
2) Кадровик создает Сотрудника для существующего ФЛ
POST /api/v1/clients/:clientId/employees
При создании Сотрудника можно указать Идентификатор Сотрудника в ИС Клиента, через поле externalId, это позволит в дальнейшем использовать внутренний (с точки зрения Клиента) идентификатор для работы с Сотрудниками
При создании Сотрудника можно сразу указать роль - Кадровика или роль Руководителя, указав соответствующий идентификатор роли в параметрах. По умолчанию Сотрудник создается без ролей.
3) Получение полного списка справочника сотрудников
GET /api/v1/clients/:clientId/employees
или
GET /api/v1/clients/:clientId/users/:snils/snils
или
GET /api/v1/clients/:clientId/employees/:externalId/externalId
или
GET /api/v1/clients/:clientId/employees/:employeeId
Получение данных необходимо, т.к. последующий запрос с приглашением выполняется только с использованием идентификаторов HRlink
При выполнении цепочки запросов данного сценария, все идентификаторы получаются в ответах на запросы и в этом случае шаг с получением данных также можно пропустить.
4) Кадровик приглашает группу сотрудников
POST /api/v1/clients/:clientId/users/invite
или
POST /api/v1/clients/:clientId/users/:clientUserId/invite
После того как ФЛ создано и ему добавлены и настроены записи Сотрудников, чтобы Работник мог воспользоваться ЛК, ему требуется направить приглашение. В группе может быть 1 и более сотрудник.
При отправке приглашения система проверяет - роли Пользователя и наличие доступных лицензий в соответствии с ролью пользователя.
Работник получив приглашение подтвердит свою учётную запись и только после этого сможет использовать ЛК в рамках Кадрового Электронного Документооборота
Пример метода можно также посмотреть - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#3.-%D0%9F%D1%80%D0%B8%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%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%D0%B5%D0%B9-%D0%BA-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B5-%D0%B2-HRlink
2. Кадровик обновляет данные ФЛ (канал уведомления) и отправляет приглашение на новый канал
Цель - отправка приглашения Сотруднику на другой канал уведомления.
1) Кадровик отменяет неподтверждённое приглашение
PUT /api/v1/clients/:clientId/users/:clientUserId/invite/deactivate
На момент составления описания данные методы не оформлены в API-документации
2) Обновление физлица по ID своей ИС
PUT /api/v1/clients/:clientId/users/:externalId/externalId
или
PUT /api/v1/clients/:clientId/users/:clientUserId
3) Кадровик приглашает группу сотрудников
POST /api/v1/clients/:clientId/users/invite
или
POST /api/v1/clients/:clientId/users/:clientUserId/invite
Пример метода можно посмотреть - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#3.-%D0%9F%D1%80%D0%B8%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%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%D0%B5%D0%B9-%D0%BA-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B5-%D0%B2-HRlink
3. Кадровик отправляет повторное приглашение
Цель - повторно пригласить сотрудника (повторно уведомить)
1) Кадровик приглашает группу сотрудников
POST /api/v1/clients/:clientId/users/invite
или
POST /api/v1/clients/:clientId/users/:clientUserId/invite
Пример метода можно посмотреть - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#3.-%D0%9F%D1%80%D0%B8%D0%B3%D0%BB%D0%B0%D1%88%D0%B5%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%D0%B5%D0%B9-%D0%BA-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B5-%D0%B2-HRlink
Сценарии работы Кадровика с ролями Пользователей
Цель сценариев - Кадровик назначает роль Руководитель сотрудникам, чтобы они в последствии могли подписывать документы от имени компании
Пользовательский Сценарий
Действия и API-методы
Примечания
0. Подготовительный этап
Цель - иметь возможность назначать роль по идентификатору
1) Кадровик получает список ролей сотрудников
GET /api/v1/employeeRoles
данные могут использоваться в сценариях создания с ролью, обновления с указанием роли и добавления роли
2) Получение полного списка справочника сотрудников
GET /api/v1/clients/:clientId/employees
данные могут использоваться для сценария добавления/удаления роли Руководителя
1. Кадровик создает сотрудника с ролью Руководитель
1) Кадровик при создание Сотрудника на основании Физ.лица задает роль Руководитель
POST /api/v1/clients/:clientId/employees
пояснения к запросу смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%A1%D0%BE%D1%82%D1%80%D1%83%D0%B4%D0%BD%D0%B8%D0%BA%D0%B0-%D1%81-%D1%80%D0%BE%D0%BB%D1%8C%D1%8E
2. Кадровый при обновлении сотрудника назначает роль Руководитель
1) Кадровик обновляет сотрудника по ID своей ИС
PUT /api/v1/clients/:clientId/employees/:externalId/externalId
или
PUT /api/v1/clients/:clientId/employees/:employeeId
3. Кадровик добавляет/убирает роль Руководитель для Сотрудника
1) Добавление роли
PUT /api/v1/clients/:clientId/employees/:employeeId/roles/add
или
Удаление роли
PUT /api/v1/clients/:clientId/employees/:employeeId/roles/remove
taskId Детализация пакетного метода - [1. (МС) Справочник юрлиц] |
|
Управление справочником Отделов
| Tip | ||
|---|---|---|
| ||
Актуализация информации о действующих Отделах. Отдел не является обязательным атрибутом для Сотрудника, но отдел используется для:
|
API-методы | Примечания | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| 1 |
GET |
методы добавления/удаления роли действуют только по идентификатору Сотрудника в HRlink
Сценарии работы Кадровика с уже сформированными данными реестра Сотрудников
Пользовательский Сценарий
Действия и API-методы
Примечания
1. Кадровик получает данные Сотрудников
Цель сценариев - получить данные по пользователям (список сотрудников, их данные и их состояния), по которым организован КЭДО в HRL.
1) Получение полного списка справочника сотрудников
GET /api/v1/clients/:clientId/employees
Кадровик получит список тех сотрудников (или данные того сотрудника), кто привязан к отделам, видимым для данного Кадрового работника.
См. схему логических связей
2) Получение данных физлица по номеру СНИЛС
GET /api/v1/clients/:clientId/users/:snils/snils
3) Получение данных сотрудника по ID своей ИС
GET /api/v1/clients/:clientId/employees/:externalId/externalId
или
GET /api/v1/clients/:clientId/employees/:employeeId
2. Кадровик обновляет данные Физлица
Цель - обновление таких данных как:
ФИО
Паспортные данные и данные документов (СНИЛС, ИНН)
Данные для Уведомления и Авторизации, в т.ч. удаление канала уведомления
1) Обновление физлица по ID своей системы
PUT /api/v1/clients/:clientId/users/:externalId/externalId
или
PUT /api/v1/clients/:clientId/users/:clientUserId
Данный шаг сценария позволяет вносить изменения в данные ФЛ:
паспорт
снилс
инн
фио
2) Установка канала уведомления сотрудника как активного
PUT /api/v1/clients/:clientId/users/:clientUserId/notificationChannels/:channelId/activate
или
DELETE /api/v1/clients/:clientId/users/:clientUserId/notificationChannels/:channelId
Данный шаг сценария позволяет вносить изменения в данные по каналам уведомления
3. Кадровик обновляет данные Сотрудника
Цель - обновление таких данных как:
Отдел
ЮЛ
Должность
Роль - Сотрудник или Руководитель
1) Кадровик обновляет данные сотрудника по ID своей ИС
PUT /api/v1/clients/:clientId/employees/:externalId/externalId
или
PUT /api/v1/clients/:clientId/employees/:employeeId
4. Кадровик присваивает почту/телефон от одного Сотрудника - другому сотруднику для приглашения
Цель - в случае использования корпоративных телефонов, почтовых адресов, которые могут передаваться от одного сотрудника к другому
1) Удаление канала уведомления Пользователя
DELETE /api/v1/clients/:clientId/users/:clientUserId/notificationChannels/:channelId
Удаление подтверждённого канала уведомление приведёт к освобождению занимаемого логина, что позволит использовать его для другого работника.
2) Обновление физлица по ID своей ИС
PUT /api/v1/clients/:clientId/users/:externalId/externalId
5. Кадровик увольняет Сотрудника
Цель - прекращение деятельности работника в занимаемой должности
1) Увольнение сотрудника по ID своей ИС
PUT /api/v1/clients/:clientId/employees/:externalId/externalId/dismiss
или
PUT /api/v1/clients/:clientId/employees/:employeeId/dismiss
В случае если после увольнения у Физлица не остается действующих Сотрудников, то система HRlink блокирует для пользователя доступ в ЛК
Данная последовательность методов не является обязательным порядком.
Это предложение, как можно организовать процесс увольнения, при котором производится чистка реестра документов от черновиков с уволены ми сотрудниками
О том, как получить черновики - см. в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#2.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B8%D1%82%D1%8C-%D1%87%D0%B5%D1%80%D0%BD%D0%BE%D0%B2%D0%B8%D0%BA%D0%B8-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2
Метод удаления документов не удаляет документы из системы безвозвратно, а помечает документ как удалённый.
2) Удаление роли
PUT /api/v1/clients/:clientId/employees/:employeeId/roles/remove
3) Кадровик получает реестр документов
POST /api/v1/clients/:clientId/documents/hrRegistry
4) Кадровик обновляет черновик документов для исключения увольняемого Сотрудника
PUT /api/v1/clients/:clientId/documentGroups
или
DELETE /api/v1/clients/:clientId/documents/:documentId
Сценарии работы Кадровика с Электронными подписями
Цель сценариев - Обеспечить сотрудника Электронной Подписью, соответствующей процессам Клиента, для выполнения КЭДО
Пользовательский Сценарий
Действия и API-методы
Примечания
1. Кадровик подключает Пользователю ПЭП Госуслуги для работы с Документами/Заявлениями
Предусловие - Служба Внедрения включила применение ПЭП Госуслуги для ЮЛ Клиента, на основании запроса
1) Кадровик разрешает применение ПЭП Госуслуги для Пользователя
PUT api/v1/clients/:clientId/employees/:employeeId/signings/prr/enable
На момент составления описания данный метод не оформлен в API-документации
метод действует только по идентификатору Сотрудника в HRlink
Метод работает по идентификатору Сотрудника, но меняет состояние Пользователя.
Т.е. если, к примеру, у Пользователя есть три сотрудника, то при включении права подписи одному из Сотрудников, включает право подписи для всех Сотрудников.
Сотруднику получившему разрешение на применение ПЭП Госуслуги при первом подписании будет необходимо авторизоваться через ЕСИА
2. Кадровик деактивирует способ подписания ПЭП Госуслуги для Пользователя
Предусловие - для вызова метода запрета нужны идентификаторы Сотрудников. СМ. получение данных сотрудников.
1) Запрет ПЭП Госуслуги
PUT api/v1/clients/:clientId/employees/:employeeId/signings/prr/disable
На момент составления описания данный метод не оформлен в API-документации
метод действует только по идентификатору Сотрудника в HRlink
3. Кадровик выпускает Пользователю УНЭП для подписания
Предусловие - Пользователь - создан, данные ФЛ (паспорт) переданы
1) Кадровик создает заявку на выпуск УНЭП
POST api/v1/clients/:clientId/users/issue/nqes
На момент составления описания данный метод не оформлен в API-документации
Пример метода можно посмотреть - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#4.-%D0%92%D1%8B%D0%BF%D1%83%D1%81%D0%BA-%D0%A3%D0%9D%D0%AD%D0%9F
2) Получение полного списка справочника сотрудников
GET /api/v1/clients/:clientId/employees
или
Получение данных сотрудника по ID своей ИС
GET /api/v1/clients/:clientId/employees/:externalId/externalId
или
GET /api/v1/clients/:clientId/employees/:employeeId
в поле lastNQESIssueRequest можно получить информацию о состоянии заявки на УНЭП
В случае отклонения заявки Сотрудником, Кадровик получит уведомление
4. Кадровик разрешает пользователю подписание УНЭП Госключ
Предусловие - разрешение происходит только по идентификатору Пользователя в системе HRL, поэтому необходимо, чтобы у Кадровика был данный идентификатор. Можно получить:
метод получения полного списка справочника сотрудников
GET /api/v1/clients/:clientId/employees
метод получения данных сотрудника по ID своей системы
GET /api/v1/clients/:clientId/employees/:externalId/externalId
метод получения данных физлица по номеру СНИЛС
GET /api/v1/clients/:clientId/users/:snils/snils
1) Кадровик разрешает применение УНЭП Госключ для Пользователя
PUT /api/v1/clients/:clientId/employees/:employeeId/signings/govkey/enable
На момент составления описания данный метод не оформлен в API-документации
метод действует только по идентификатору Сотрудника в HRlink
Сотруднику получившему разрешение на применение ПЭП Госуслуги при первом подписании будет необходимо авторизоваться через ЕСИА
Формирование Кадрового Документооборота
| Info |
|---|
Документ - объект направляемый Работодателем работнику для ознакомления или подписания, в рамках КЭДО. Документ состоит из метаданных и файлов, обладает состоянием, которое определяется процессом. Участники КЭДО могут совершать различные операции, которые зависят от роли и условий и состояния документа В данном описании рассмотрено, с какими сценариями может столкнуться работодатель в рамках взаимодействия своей информационной системы (в которой организован КЭДО) и системой HRlink. |
Сценарии Кадровика по Инициированию КЭДО
Цель - начать КЭДО для необходимых сотрудников компании Клиента.
Порядок действий
Действия и API-методы
Примечания
1. Кадровик создает и отправляет на подписание документ
1) Кадровик загружает файла(ы) для документа(ов)
POST /api/v1/files
Поле, в котором передается файл, может иметь любое имя.
В одном запросе можно передать один или несколько файлов. В случае отправки нескольких файлов следует давать полям разные имена.
При создании документа система конвертирует полученный файл в pdf/a. Конвертация файла является асинхронным процессом!
2) Кадровик получает список доступных типов документов
GET /api/v1/permittedDocumentTypes
Использование данного шага как части сценария позволит получить актуальный список типов документов для Кадровика
3) Кадровик создает черновик документа
POST /api/v1/clients/:clientId/documentGroups
При создании можно задавать Внешний ID (externalId), соответствующий идентификатору документа в вашей ИС. В HRlink Внешний ID (externalId) хранится как строка, поэтому допустимы любые строковые символы. Ограничения на максимальную длину строки нет.
4) Кадровик инициирует проверку на возможность отправки на подписание
POST /api/v1/clients/:clientId/documents/validateBeforeSendToSigning
5) Кадровик отправляет документ на подписание
PUT /api/v2/clients/:clientId/documents/sendToSigning
Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#7.-%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D0%BA-%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B
2. Кадровик подписывает Черновик (как руководитель) и отправляет дальше на подписание
Предусловие - Документ был создан (например, выполнены шаги 1-3 сценария 1)
1) Кадровик инициирует проверку документов на возможность подписания и отправки на подписание
POST /api/v1/clients/:clientId/documents/validateBeforeSendAndSign
2) Кадровик запрашивает файл, который подписывается в HRlink
GET /api/v1/clients/:clientId/documents/:documentId/convertedFile
Необходимо получить файл, который был получен в HRlink после конвертации переданного файла в формат pdf/a.
Подписание УКЭПом должно производиться именно относительно файла, полученного в данном методе
3) Кадровик подписывает УКЭП (как руководитель) и отправляет документ дальше
PUT /api/v1/clients/:clientId/documents/sendAndSign
Само подписание УКЭПом производится за рамками HRlink, в данном методе только передаётся файл подписи
Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#7.-%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D0%BA-%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B
3. Кадровик создает документ с отправкой на подписание при создании
Предусловие - файлы для документа загружен с помощью метода загрузки файла
POST /api/v1/files
1) Кадровик использует метод отправки документа на подписание при создании
POST /api/v1/clients/:clientId/documentGroups/sendToSigning
2) Кадровик запрашивает массив документов с заданными фильтрами
POST /api/v1/clients/:clientId/documents/hrRegistry
данный метод необходим в качестве проверки состояния документов, которые были созданы с совмещённой отправкой.
Проверка может быть периодической, до тех пор, пока по всем созданным документам не будет получено состояние означающее что документ был создан и отправлен на подписание.
Необходимость проверки обусловлена ассинхронностью процесса.
4. Кадровик отправляет на подписание ранее созданный черновик
Предусловие - черновик документа создан
1) Кадровик инициирует проверку на возможность отправки на подписание
POST /api/v1/clients/:clientId/documents/validateBeforeSendToSigning
2) Кадровик отправляет черновик документа на подписание
PUT /api/v2/clients/:clientId/documents/sendToSigning
Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#7.-%D0%9A%D0%B0%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D0%BA-%D0%BE%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B
Контроль Процесса Подписания
Сценарии Кадровика по работе с уже созданными документами
Порядок действий
Действия и API-методы
Примечания
1. Кадровик получает данные по документам, в том числе файлы по конкретному документу
Цель - обновить данные по документам в ИС Клиента, в том числе если требуется - добавление файлов
1) Кадровик запрашивает список документов с учётом фильтров
POST /api/v1/clients/:clientId/documents/hrRegistry
Список документов возвращается частями, которые определяется двумя параметрами - лимит и сдвиг выгрузки
Когда в возвращаемом срезе документов будет меньше чем в лимите среза, значит это последняя часть
Подробнее о параметрах запроса для фильтрации и том, как определять состояние документов по признакам см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#I.-%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D1%8B-%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5-%D1%81-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8 и в описании метода
2) Кадровик запрашивает документ по ID своей ИС
GET /api/v1/clients/:clientId/documents/:externalId/externalId
или
GET /api/v1/clients/:clientId/documents/:documentId
3) Кадровик получает печатную форму документа с оттисками
GET /api/v1/clients/:clientId/documents/:documentId/printFormFile
или
GET /api/v1/clients/:clientId/documents/:documentId/convertedFile
Оригинальный файл, который был загружен не выгружается по API-методам и не входит в состав Архива КЭДО, поэтому при необходимости получения оригинального файла необходим запрос в службу поддержки
На момент составления описания метод получения ПФ документа не оформлен в API-документации
2. Кадровик редактирует параметры черновика
Предусловие - документ создан, но не был отправлен
Цель - внести изменения в метаданные документа:
тип, номер, дата
актуализировать состав участников
1) Кадровик вносит исправления в данные черновика документа
PUT /api/v1/clients/:clientId/documentGroups
Обновление происходит только внутри группы документов
2) используется один из описанных сценариев инициирования КЭДО
3. Кадровик заменяет Черновик
4. Кадровик заменят документ, находящийся на подписании
Цель - заменить файл документа или внести исправления в документ находящийся на подписании
1) Кадровик удаляет документ по ID документа в HRL
DELETE /api/v1/clients/:clientId/documents/:documentId
или
DELETE/api/v1/clients/:clientId/ |
При необходимости удалить 1 документ по идентификатору из своей ИС, нужно использовать метод удаления группы документов и в теле запроса передать список из одного документа с указанием идентификатора своей ИС
2) Кадровик затирает ID своей ИС в удаленном документе
departments | Данный шаг можно пропустить, т.к. он нужен только для получения списка идентификаторов, чтобы производить обновления по конкретному Отделу | ||||||||
| 2 |
|
PUT /api/v1/clients/:clientId |
3) Используется один из подходящих сценариев инициирования КЭДО
5. Кадровик выгружает архив КЭДО
Цель - реализовать выгрузку архивов КЭДО
для бекапирования
для наполнения своей ИС архивами
1) Кадровик получает список документов с соответствии с фильтрами
/departments/:externalId/externalId или
PUT api/v1/clients/:clientId/departments/:departmentId или использовать пакетный метод, для выгрузки отделов 1) Создать новую задачу массовой синхронизации данных
|
POST /api/v1/clients/:clientId/ |
Данный шаг нужен для того, чтобы получить список документов, по которым требуется выгрузка архивов, однако если при создании документов используются идентификаторы своей системы, и список документов полностью управляется на стороне ИС Клиента, то данный шаг можно пропустить
2) Кадровик скачивает архив КЭДО по ID документа своей ИС
GET /api/v1/clients/:clientId/documents/:externalId/externalId/archive
или
bulkDataSyncTasks 2) Получить статус задачи массовой синхронизации данных по идентификатору задачи
|
GET /api/v1/clients/:clientId/ |
Получив список документов, в соответствии с фильтрами, по каждому документу вызывается метод получения архива КЭДО.
В случае, если выгрузка реализована для бекапирования необходимо со своей стороны отмечать - по каким документам архивы уже были выгружены.
Архив КЭДО содержит в себе:
сконвертированный файл
файлы подписей
печатную форму документа с оттисками
6. Кадровик инициирует повторное уведомления для подписантов
Цель - побудить участника КЭДО к подписанию
| |||||||||
| 3 |
DELETE |
1) Кадровик получает список документов с соответствии с фильтрами
POST/api/v1/clients/:clientId |
Подробнее о параметрах запроса для фильтрации и том, как определять состояние документов по признакам см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#I.-%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D1%8B-%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5-%D1%81-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8
2) Кадровик инициирует повторное уведомление по документу
POST /api/v1/clients/:clientId/documents/signers/next/notify
На момент составления описания данные метод не оформлен в API-документации
Кадровому работнику не требуется определять на ком “зависло” подписание, система сама направляет уведомление текущему подписанту, с учётом того, какой канал уведомления является актуальным для Подписанта.
7. Кадровик добавляет заметку к документу
Предусловие - известен идентификатор документа
Кадровик добавляет текст заметки к документу
PUT /api/v1/clients/:clientId/documents/:documentId/notice
На момент составления описания данные метод не оформлен в API-документации
Заметка, оставленная Кадровиком видна только Кадровику, включая тех у кого есть права на просмотр документа
Обработка Заявлений
| Info |
|---|
Заявление - кадровый документ, подписание которого инициировано Работником
В данном разделе описывается функционал по отношению к Кадровику. Описание возможностей Сотрудника по работе с заявлениями указаны в |
1. Сценарии работы Кадровика с Шаблонами заявлений
| Info |
|---|
Пример файла шаблона заявления можно скачать ниже. В файле шаблона заявления переменные оформляются следующим образом: <<[имя_переменной]>>
|
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
/departments/:departmentId | Удаление рассматривается как частный случай обновления. |
Управление справочником Должностей
| Tip | ||
|---|---|---|
| ||
Актуализация информации о действующих должностях. Должность не является обязательным атрибутом для Сотрудника, если интеграция не предполагает использования интерфейса HRlink, то можно отказаться от управления данным справочником. Однако Использование должностей в значительной степени влияет на использования функционала ЛНА. |
API-методы | Примечания | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
POST/api/v1/clients/:clientId/employeePositions или использовать пакетный метод, для выгрузки отделов 1) Создать новую задачу массовой синхронизации данных POST /api/v1/clients/:clientId/bulkDataSyncTasks 2) Получить статус задачи массовой синхронизации данных по идентификатору задачи GET /api/v1/clients/:clientId/bulkDataSyncTasks/:taskId | Первичное наполнение справочника должностей может быть организовано или через использование пакетного метода выгрузки
| ||||||||||||||||||||||||||
| 2 |
GET /api/v1/clients/:clientId/employeePositions | Данный шаг можно пропустить, т.к. он нужен только для получения списка идентификаторов, чтобы производить обновления по конкретной Должности или использовать идентификаторы должностей в связанных методах. Также при точечном создании должности в ответ возвращается идентификатор должности | ||||||||||||||||||||||||||
| 3 |
PUT |
Сценарий
Действия и API-метод
Примечания
1. Кадровый работник обновляет файл шаблона действующего заявления
Предусловия
шаблон заявления создан через службу поддержки
есть идентификатор шаблона заявления
GET /api/v1/applicationTypes
есть список системных полей (единый для всех шаблонов заявлений), которые можно использовать для настройки файла шаблона (подставлять в необходимые места шаблона)
GET /api/v1/applicationTypeFields/system
Цель - актуализировать файл шаблона
общий файл
файл шаблона для конкретного ЮЛ
1) Получение файла шаблона заявления
GET/api/v1/clients/:clientId/ |
employeePositions/: |
2) Кадровик загружает заранее подготовленный файл шаблона Заявления
/api/v1 |
Полученный идентификатор файла будет передаваться в следующем методе
Для каждого ЮЛ может быть свой файл шаблона заявления (см. схему)
/clients/:clientId/employeePositions/:positionId |
| ||||||||
| 4 |
DELETE |
3) Кадровик заменяет идентификатор файла на новый шаблон
PUT/api/v1/ |
clients/: |
Данный метод позволяет:
Загрузить новый файл шаблона заявления
Активировать/Деактивировать шаблон заявления
Обновить состав пользовательских полей в шаблоне
Обновить имя шаблона
2. Кадровик обновляет параметры загруженного Шаблона Заявления
Предусловие - есть идентификатор шаблона заявления
GET /api/v1/applicationTypes
Цель - актуализировать информацию в шаблоне заявления:
сделать шаблон видимым/скрытым для сотрудников
обновить имя шаблона
PUT /api/v1/applicationTypes/:applicationTypeId
2. Сценарии работы Кадровика с поданными Заявлениями
Порядок действий
API-метод
Примечания
1. Кадровик получает реестр Заявлений по конкретному заявителю/согласующему
Предусловие - в системе Клиента нет идентификатора Сотрудника HRL и используются только идентификаторы своей системы
1) Кадровик получает данные сотрудника по ID в своей ИС
GET /api/v1/clients/:clientId/employees/:externalId/externalId
Идентификатор Сотрудника в HRL смотрим в employee -> legalEntities -> employeeId
или
Кадровик получает данные ФЛ по СНИЛС
GET /api/v1/clients/:clientId/users/:snils/snils
Цель данного шага - получить идентификатор сотрудника в системе HRL, по которому требуется получить список заявлений, как по:
Заявителю
Согласующему
В случае, если в системе Клиента хранится связка идентификаторов Сотрудника HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить
2) Кадровик получает список Заявлений
POST /api/v1/clients/:clientId/applicationGroups/hrRegistry
Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9
2. Кадровик получает реестр Заявлений по отделу Заявителя
Предусловие - в системе Клиента нет идентификатора Отдела HRL и используются только идентификаторы своей системы
1) Кадровик получает справочник отделов
GET /api/v1/clients/:clientId/departments
Идентификатор Сотрудника в HRL смотрим в clientDepartments -> id
Цель данного шага - получить идентификатор отдела в HRL
В случае, если в системе Клиента хранится связка идентификаторов Отдела HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить
2) Кадровик получает список Заявлений по отделам заявителя
POST /api/v1/clients/:clientId/applicationGroups/hrRegistry
Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9
3. Кадровик получает реестр Заявлений по конкретному ЮЛ
Предусловие - в системе Клиента нет идентификатора Отдела HRL и используются только идентификаторы своей системы
1) Кадровик получает справочник Юрлиц
GET /api/v1/clients/:clientId/legalEntities
Идентификатор Юрлица в HRL смотрим в legalEntities -> id
Цель данного шага - получить идентификатор отдела в HRL
В случае, если в системе Клиента хранится связка идентификаторов Юрица HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить
2) Кадровик получает список Заявлений по Юрлицам
POST /api/v1/clients/:clientId/applicationGroups/hrRegistry
Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9
4. Кадровик получает все данные по Заявлениям с учётом всех фильтров
Цель - получить список заявлений по произвольному набору фильтров
POST /api/v1/clients/:clientId/applicationGroups/hrRegistry
Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9
5. Кадровик получает данные конкретного заявления (метаданные, файлы и архив)
Предусловие - по одному из сценариев выше есть идентификатор заявления
1) Кадровик получает данные заявления по ID в HRL
GET /api/v1/clients/:clientId/applicationGroups/:applicationGroupId
На метаданные заявления содержат в себе:
Данные Заявителя и Согласующего
Данные Заявления: Группа, Дата, Номер
2) Кадровик получает:
GET /api/v1/clients/:clientId/applications/:applicationId/printFormFile
файл, который подписан
GET /api/v1/clients/:clientId/applications/:applicationId/convertedFile
GET /api/v1/clients/:clientId/applications/:applicationId/archive
Печатная форма заявления может быть использована для отображения.
В случае, если Кадровику достаточно метаданных, полученных из заявления, то шаг с получением файла заявления можно пропустить
На данный момент метод получения, подписываемого файла заявления, не оформлен в API-документации
6. Кадровик обрабатывает Заявление
Предусловие - по одному из сценариев выше есть идентификатор заявления
кадровик получает реестр заявлений, ожидающих обработки Кадровиком
1) Кадровик берёт заявление в работу
PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/claim
Данный шаг может быть пропущен, если у Клиента после получения заявления сразу выносится решение от Кадровика и не требуется вести учёт того, какие заявления находятся в работе в моменте.
2) Кадровик принимает решение по заявлению:
PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/process
PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/rejectclientId/employeePositions/:positionId |
|
Управление справочником Типов Документов
| Tip | ||
|---|---|---|
| ||
Тип документа - не является обязательным для создания документа, однако имеет большое значение в управлении ЛНА и может быть связан с развитием функционала системы HRlink |
API-методы | Примечания | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
GET /api/v1/documentTypes | При создании пространства Клиента, HRlink передает базовый список типов документов, с которых уже можно начинать работу. Поэтому чтобы не создавать дублирующие типы заявлений может быть полезным сперва изучить заданные типы документов. Однако созданный Типы документов можно наполнить идентификаторами ИС Клиента и управлять видимостью типов документов. | ||||||||||||||||
| 2 |
PUT /api/v2/documentTypes/:documentTypeExternalId/externalId
PUT /api/v2/documentTypes/:documentTypeId | Для типов документов, созданных Администратором можно обновить все параметры.
|
Управление справочником Шаблонов Заявлений
| Tip | ||
|---|---|---|
| ||
Подготовить справочник Шаблонов Заявлений, которыми сможет воспользоваться Сотрудник при подаче Заявлений. К подготовке можно отнести актуализацию - корректировку имён шаблонов и видимость для Сотрудника при подаче |
| Note | ||
|---|---|---|
| ||
Первичное создание шаблона заявления сейчас доступно только через обращение в Службу Заботы о Клиентах, дальнейшее использование и настройка - доступны как в ЛК, так и по API Подробнее о заявлениях см. раздел Заявление |
| Expand | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
В файле шаблона заявления переменные оформляются следующим образом: <<[имя_переменной]>>
|
API-методы | Примечания | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
GET /api/v1/applicationTypes | Для того, чтобы Сотрудник мог подавать заявления из шаблона, требуется настроить шаблоны. Настройка шаблонов идёт с указанием идентификатора шаблона
| ||||||||||||||||
| 2 |
GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile | Шаблонный файл может быть доработан Клиентом в плане содержания статического текста и размещения доступных переменных, значения которых будут использоваться при генерации заявления из шаблона. Клиент так же может задать собственное форматирование файла - шрифты, кегель, отступы и т.д. Оформление шаблона происходит вне рамок информационных систем. | ||||||||||||||||
| 3 |
GET /api/v1/applicationTypeFields/system | Системные поля - это поля, которые предопределены HRlink и являются общими для всех типов заявлений.
| ||||||||||||||||
| 4 |
POST /api/v1/files | Поле, в котором передается файл, может иметь любое имя. В одном запросе можно передать один или несколько файлов. В случае отправки нескольких файлов следует давать полям разные имена. Для Каждого ЮЛ на один тип Заявления может быть задан собственный шаблон. | ||||||||||||||||
| 5 |
PUT /api/v4/applicationTypes/:applicationTypeId
PUT /api/v1/applicationTypes/:applicationTypeId/sortOrder | При обновлении Кадровик
|
Предыдущий раздел
Следующий раздел
Поиск документации
| Livesearch | ||||
|---|---|---|---|---|
|