| 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. Кадровый работник обновляет файл шаблона действующего заявления
Предусловия
шаблон заявления создан через службу поддержки
есть идентификатор шаблона заявления
GET /api/v1/applicationTypes
есть список системных полей (единый для всех шаблонов заявлений), которые можно использовать для настройки файла шаблона (подставлять в необходимые места шаблона)
GET /api/v1/applicationTypeFields/system
Цель - актуализировать файл шаблона
общий файл
файл шаблона для конкретного ЮЛ
1) Получение файла шаблона заявления
GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile
2) Кадровик загружает заранее подготовленный файл шаблона Заявления
POST /api/v1/files
Полученный идентификатор файла будет передаваться в следующем методе
Для каждого ЮЛ может быть свой файл шаблона заявления (см. схему)
3) Кадровик заменяет идентификатор файла на новый шаблон
PUT /api/v1/applicationTypes/:applicationTypeId
Данный метод позволяет:
Загрузить новый файл шаблона заявления
Активировать/Деактивировать шаблон заявления
Обновить состав пользовательских полей в шаблоне
Обновить имя шаблона
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/reject
Предыдущий раздел
Поиск документации
| Livesearch | ||||
|---|---|---|---|---|
|