Под формирование кадрового документооборота подразумевается:

  1. Создание и редактирование Черновика Документа
  2. Отправление документов на подписание
    1. Отправление Черновика на подписание
    2. Создание Черновика, совмещённое с отправкой на подписание
    3. Отправление Черновика, совмещённое с подписанием от лица Работодателя
  3. ЛНА - создание, отправка на подписание

...

...



Формирование Кадрового Документооборота

Документ - объект направляемый Работодателем работнику для ознакомления или подписания, в рамках КЭДО.

Документ состоит из метаданных и файлов, обладает состоянием, которое определяется процессом.

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

В данном описании рассмотрено, с какими сценариями может столкнуться работодатель в рамках взаимодействия своей информационной системы (в которой организован КЭДО) и системой 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

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#6.-%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F

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

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#6.-%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F

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

Подробнее описание метода смотри - https://hr-link.atlassian.net/wiki/spaces/HRLIN/pages/666075304/04.#6.-%D0%9F%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B0-%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F

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


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

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


7. Кадровик добавляет заметку к документу

Предусловие - известен идентификатор документа

  • Кадровик добавляет текст заметки к документу

PUT /api/v1/clients/:clientId/documents/:documentId/notice

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

Заметка, оставленная Кадровиком видна только Кадровику, включая тех у кого есть права на просмотр документа



Обработка Заявлений

Заявление - кадровый документ, подписание которого инициировано Работником

  • Работа с реестром Заявлений

  • Работа с Заявлением

В данном разделе описывается функционал по отношению к Кадровику.

Описание возможностей Сотрудника по работе с заявлениями указаны в

1. Сценарии работы Кадровика с Шаблонами заявлений

Пример файла шаблона заявления можно скачать ниже.

В файле шаблона заявления переменные оформляются следующим образом:

<<[имя_переменной]>>

  • Для переменных типа дата, доступно указание формата даты, например - <<[dateVacation]:"dd.MM.yyyy">>

  • имя переменной определяется:

    • При создании шаблона заявления

    • При обновлении шаблона заявления


Сценарий

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

Примечания

1. Кадровый работник обновляет файл шаблона действующего заявления

Предусловия

  1. шаблон заявления создан через службу поддержки

  2. есть идентификатор шаблона заявления

    1. список Шаблонов Заявлений

    2. GET /api/v1/applicationTypes

  3. есть список системных полей (единый для всех шаблонов заявлений), которые можно использовать для настройки файла шаблона (подставлять в необходимые места шаблона)

    1. список системных полей

    2. 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

Данный метод позволяет:

  1. Загрузить новый файл шаблона заявления

  2. Активировать/Деактивировать шаблон заявления

  3. Обновить состав пользовательских полей в шаблоне

  4. Обновить имя шаблона


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


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



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