| Excerpt | ||||||
|---|---|---|---|---|---|---|
|
Основные задачи Кадрового специалиста
Кадровый специалист отвечает за документооборот. Что именно это означает? Рассмотрим основные функции.
01. Кадровик. Вспомогательные процессы: Управление структурой и Справочниками
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
02. Кадровик. Основные процессы: Управление Персоналом
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
03. Кадровик. Основные процессы: Формирование и контроль Документооборота
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
04. Кадровик. Основные процессы: Обработка Заявлений
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
Формирование Кадрового Документооборота
| 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/documents
При необходимости удалить 1 документ по идентификатору из своей ИС, нужно использовать метод удаления группы документов и в теле запроса передать список из одного документа с указанием идентификатора своей ИС
2) Кадровик затирает ID своей ИС в удаленном документе
PUT /api/v1/clients/:clientId/documents/:externalId/externalId/clearExternalId
3) Используется один из подходящих сценариев инициирования КЭДО
5. Кадровик выгружает архив КЭДО
Цель - реализовать выгрузку архивов КЭДО
для бекапирования
для наполнения своей ИС архивами
1) Кадровик получает список документов с соответствии с фильтрами
POST /api/v1/clients/:clientId/documents/hrRegistry
Данный шаг нужен для того, чтобы получить список документов, по которым требуется выгрузка архивов, однако если при создании документов используются идентификаторы своей системы, и список документов полностью управляется на стороне ИС Клиента, то данный шаг можно пропустить
2) Кадровик скачивает архив КЭДО по ID документа своей ИС
GET /api/v1/clients/:clientId/documents/:externalId/externalId/archive
или
GET /api/v1/clients/:clientId/documents/:documentId/archive
Получив список документов, в соответствии с фильтрами, по каждому документу вызывается метод получения архива КЭДО.
В случае, если выгрузка реализована для бекапирования необходимо со своей стороны отмечать - по каким документам архивы уже были выгружены.
Архив КЭДО содержит в себе:
сконвертированный файл
файлы подписей
печатную форму документа с оттисками
6. Кадровик инициирует повторное уведомления для подписантов
Цель - побудить участника КЭДО к подписанию
1) Кадровик получает список документов с соответствии с фильтрами
POST /api/v1/clients/:clientId/documents/hrRegistry
Подробнее о параметрах запроса для фильтрации и том, как определять состояние документов по признакам см. раздел https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#I.-%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D1%8B-%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5-%D1%81-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8
2) Кадровик инициирует повторное уведомление по документу
POST /api/v1/clients/:clientId/documents/signers/next/notify
На момент составления описания данные метод не оформлен в API-документации
Кадровому работнику не требуется определять на ком “зависло” подписание, система сама направляет уведомление текущему подписанту, с учётом того, какой канал уведомления является актуальным для Подписанта.
7. Кадровик добавляет заметку к документу
Предусловие - известен идентификатор документа
Кадровик добавляет текст заметки к документу
PUT /api/v1/clients/:clientId/documents/:documentId/notice
На момент составления описания данные метод не оформлен в API-документации
Обработка Заявлений
| Info |
|---|
Заявление - кадровый документ, подписание которого инициировано Работником
В данном разделе описывается функционал по отношению к Кадровику. Описание возможностей Сотрудника по работе с заявлениями указаны в |
1. Сценарии работы Кадровика с Шаблонами заявлений
| Info |
|---|
Пример файла шаблона заявления можно скачать ниже. В файле шаблона заявления переменные оформляются следующим образом: <<[имя_переменной]>>
|
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Сценарий | Действия и API-метод | Примечания |
|---|---|---|
1. Кадровый работник обновляет файл шаблона действующего заявленияПредусловия
Цель - актуализировать файл шаблона
| 1) Получение файла шаблона заявления GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile | |
2) Кадровик загружает заранее подготовленный файл шаблона Заявления POST /api/v1/files | Полученный идентификатор файла будет передаваться в следующем методе Для каждого ЮЛ может быть свой файл шаблона заявления (см. схему) | |
3) Кадровик заменяет идентификатор файла на новый шаблон PUT /api/v1/applicationTypes/:applicationTypeId | Данный метод позволяет:
| |
2. Кадровик обновляет параметры загруженного Шаблона ЗаявленияПредусловие - есть идентификатор шаблона заявления
Цель - актуализировать информацию в шаблоне заявления:
| PUT /api/v1/applicationTypes/:applicationTypeId | |
2. Сценарии работы Кадровика с поданными Заявлениями
Порядок действий | API-метод | Примечания |
|---|---|---|
1. Кадровик получает реестр Заявлений по конкретному заявителю/согласующемуПредусловие - в системе Клиента нет идентификатора Сотрудника HRL и используются только идентификаторы своей системы | 1) Кадровик получает данные сотрудника по ID в своей ИС GET /api/v1/clients/:clientId/employees/:externalId/externalId Идентификатор Сотрудника в HRL смотрим в employee -> legalEntities -> employeeId или Кадровик получает данные ФЛ по СНИЛС GET /api/v1/clients/:clientId/users/:snils/snils | Цель данного шага - получить идентификатор сотрудника в системе HRL, по которому требуется получить список заявлений, как по:
В случае, если в системе Клиента хранится связка идентификаторов Сотрудника HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить |
2) Кадровик получает список Заявлений POST /api/v1/clients/:clientId/applicationGroups/hrRegistry | Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9 | |
2. Кадровик получает реестр Заявлений по отделу ЗаявителяПредусловие - в системе Клиента нет идентификатора Отдела HRL и используются только идентификаторы своей системы | 1) Кадровик получает справочник отделов GET /api/v1/clients/:clientId/departments Идентификатор Сотрудника в HRL смотрим в clientDepartments -> id | Цель данного шага - получить идентификатор отдела в HRL В случае, если в системе Клиента хранится связка идентификаторов Отдела HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить |
2) Кадровик получает список Заявлений по отделам заявителя POST /api/v1/clients/:clientId/applicationGroups/hrRegistry | Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9 | |
3. Кадровик получает реестр Заявлений по конкретному ЮЛПредусловие - в системе Клиента нет идентификатора Отдела HRL и используются только идентификаторы своей системы | 1) Кадровик получает справочник Юрлиц GET /api/v1/clients/:clientId/legalEntities Идентификатор Юрлица в HRL смотрим в legalEntities -> id | Цель данного шага - получить идентификатор отдела в HRL В случае, если в системе Клиента хранится связка идентификаторов Юрица HRL и идентификаторов в ИС Клиента, то данный шаг можно пропустить |
2) Кадровик получает список Заявлений по Юрлицам POST /api/v1/clients/:clientId/applicationGroups/hrRegistry | Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9 | |
4. Кадровик получает все данные по Заявлениям с учётом всех фильтровЦель - получить список заявлений по произвольному набору фильтров | POST /api/v1/clients/:clientId/applicationGroups/hrRegistry | Подробнее смотри примеры методов получения заявлений и определения состояния заявлений в разделе https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#1.-%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80%D0%B0-%D0%97%D0%B0%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9 |
5. Кадровик получает данные конкретного заявления (метаданные, файлы и архив)Предусловие - по одному из сценариев выше есть идентификатор заявления | 1) Кадровик получает данные заявления по ID в HRL GET /api/v1/clients/:clientId/applicationGroups/:applicationGroupId | На метаданные заявления содержат в себе:
|
2) Кадровик получает: GET /api/v1/clients/:clientId/applications/:applicationId/printFormFile
GET /api/v1/clients/:clientId/applications/:applicationId/convertedFile GET /api/v1/clients/:clientId/applications/:applicationId/archive | Печатная форма заявления может быть использована для отображения. В случае, если Кадровику достаточно метаданных, полученных из заявления, то шаг с получением файла заявления можно пропустить На данный момент метод получения, подписываемого файла заявления, не оформлен в API-документации | |
6. Кадровик обрабатывает ЗаявлениеПредусловие - по одному из сценариев выше есть идентификатор заявления
| 1) Кадровик берёт заявление в работу PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/claim | Данный шаг может быть пропущен, если у Клиента после получения заявления сразу выносится решение от Кадровика и не требуется вести учёт того, какие заявления находятся в работе в моменте. |
2) Кадровик принимает решение по заявлению: PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/process PUT /api/v1/clients/:clientId/applications/:applicationId/participants/hr/reject | ||
Предыдущий раздел
Следующий раздел
Поиск документации
| Livesearch | ||||
|---|---|---|---|---|
|