Versions Compared

Old Version 5

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

Saved on

compared with

New Version Current

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

Saved on

Key

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

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

  1. МЧД - получение списка доверенностей, получение данных доверенности

    1. (warning) Созданием МЧД занимается Администратор → [01. Администратор. Базовые настройки справочников]

  2. Создание и редактирование Черновика Документа

  3. Отправление документов на подписание

    1. Отправление Черновика на подписание

    2. Создание Черновика, совмещённое с отправкой на подписание

    3. Отправление Черновика, совмещённое с подписанием от лица Работодателя

  4. ЛНА - создание, отправка на подписание

Table of Contents

Tip
titleЦель

...

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

...

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

Info

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

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

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

В данном описании рассмотрено, с какими сценариями может столкнуться работодатель в рамках взаимодействия своей информационной системы (в которой организован КЭДО) и системой HRlink.

Сценарии Кадровика по Инициированию КЭДО

Tip
titleЦель
- начать


Начать КЭДО для необходимых сотрудников компании Клиента

.


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

Только действующий сотрудник с правом подписания (это или включенная возможность подписания или действующий УНЭП) имеет право участвовать в КЭДО.

Кадровик создает Черновик Документа и отправляет его на подписание

(warning) для понимания процесса работы с документами рекомендуется изучить раздел [Документ]


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

Примечания

1

Порядок действий

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

Примечания

1. Кадровик создает и отправляет на подписание документ

1) Кадровик загружает файла(ы) для документа(ов)

POST /api/v1/files

Status
subtletrue
colourGreen
titleredoc

 POST /api/v1/files 

Поле, в котором передается файл, может иметь любое имя.

В одном запросе можно передать один или несколько файлов. В случае отправки нескольких файлов следует давать полям разные имена.

При создании документа система конвертирует полученный файл в pdf/a. Конвертация файла является асинхронным процессом!
2

2) Кадровик получает список доступных типов документов

Status
subtletrue
colourGreen
titleredoc

 GET /api/v1/

permittedDocumentTypes

permittedDocumentTypes 

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

3

3) Кадровик создает черновик документа

Status
subtletrue
colourGreen
titleredoc

 POST /api/v1/clients/:clientId/

documentGroups

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

При создании документа система конвертирует полученный файл в pdf/a. Конвертация файла является асинхронным процессом!

Создание документа возможно только если в системе HRlink есть файл, который ляжет в основу подписания. То есть есть два варианта для связи набора метаданных документа с файлом:

  • через указание идентификатора файла (возвращается в ответ на вызов метода загрузки файла)
  • через указание документа основания sourceDocumentId или sourceDocumentExternalId
4

4) Кадровик инициирует проверку на возможность отправки на подписание

Status
subtletrue
colourGreen
titleredoc

 POST /api/v1

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

validateBeforeSendToSigning 

Валидация не является обязательным шагом, но помогает произвести проверку множества документов на возможность отправки.

5

5) Кадровик вносит исправления в данные черновика документа

Status
subtletrue
colourGreen
titleredoc

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


частный случай исправления - затирание externalId документа и повторение шагов 1-4

5) Кадровик затирает ID своей ИС в удаленном документе

Status
subtletrue
colourGreen
titleredoc

 PUT /api/

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

:externalId/externalId/clearExternalId 


альтернативой редактированию может быть удаление черновика и повторение шагов 1-4

5) Кадровик удаляет документ по ID документа в HRL

Status
subtletrue
colourGreen
titleredoc

 DELETE

GET

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

/convertedFile

Необходимо получить файл, который был получен в HRlink после конвертации переданного файла в формат pdf/a.

Подписание УКЭПом должно производиться именно относительно файла, полученного в данном методе

3) Кадровик подписывает УКЭП (как руководитель) и отправляет документ дальше

 

или

 DELETE /api/

PUT /api/

v1/clients/:clientId/

documents/sendAndSign

documents 

В случае, если после валидации получена информация о том, что блокирует отправку документа, то черновик можно отредактировать.

Редактирование черновика позволяет внести изменения в метаданные документа:

  • тип, номер, дата

  • актуализировать состав участников


(warning) редактирование не позволяет заменить файл

6

6) Кадровик отправляет документ на подписание

Status
subtletrue
colourGreen
titleredoc

PUT /api/v1/clients/{clientId}/documents/sendToSigning

В случае, если требуется выполнение именно этого шага, для уже созданных Черновиков, то необходимо будет получить список документов в состоянии Черновик.


Кадровик подписывает Черновик (как руководитель) и отправляет дальше на подписание

Note
titleПредусловие
  1. Выполнены шаги 1-3 сценария [Кадровик создает Черновик Документа и отправляет его на подписание]
  2. Есть идентификатор документа

Само подписание УКЭПом производится за рамками 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) Кадровик запрашивает массив документов с заданными фильтрами


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

Примечания

1

1) Кадровик инициирует проверку документов на возможность подписания и отправки на подписание

Status
subtletrue
colourYellow
titleGdoc

 

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

hrRegistry

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

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

Необходимость проверки обусловлена ассинхронностью процесса.

validateBeforeSendAndSign 

Валидация не является обязательным шагом, но помогает произвести проверку множества документов

2

2) Кадровик запрашивает файл, который подписывается в HRlink

Status
subtletrue
colourYellow
titleGdoc

 GET

4. Кадровик отправляет на подписание ранее созданный черновик

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

1) Кадровик инициирует проверку на возможность отправки на подписание

POST

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

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

convertedFile 

Необходимо получить файл, который был получен в HRlink после конвертации переданного файла в формат pdf/a.

Подписание УКЭПом должно производиться именно относительно файла, полученного в данном методе

3

3) Кадровик подписывает УКЭП (как руководитель) и отправляет документ дальше

Status
subtletrue
colourYellow
titleGdoc

 PUT /api/v1

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

Контроль Процесса Подписания

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

sendAndSign 

Само подписание УКЭПом производится за рамками HRlink, в данном методе только передаётся файл подписи.

(warning) если включена настройка использования МЧД, то требуется учитывать права Подписанта в рамках МЧД


Кадровик создает Черновик с совмещённой отправкой на подписание при создании

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

(warning) если включена настройка использования МЧД, то требуется учитывать права Подписанта в рамках МЧД

Файлы для документа загружен с помощью метода загрузки файла

Порядок действий


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

Примечания

1
. Кадровик получает данные по документам, в том числе файлы по конкретному документу

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

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

Status
subtletrue
colourYellow
titleGdoc

 POST /api/

1) Кадровик запрашивает список документов с учётом фильтров

POST /api/

v1/clients/:clientId/

documents

documentGroups/

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

sendToSigning 

Выполнение метода является ассинхронным, поэтому в ответ возвращается не идентификатор документа, а идентификатор задачи.

2

2) Кадровик запрашивает массив документов с заданными фильтрами

Status
subtletrue
colourYellow
titleGdoc

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

Необходимость проверки обусловлена ассинхронностью процесса.

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

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

Контроль Процесса Подписания

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

Получение метаданных документа 

Tip
titleЦель


В разделе [REST API - "Запрос-Ответ"] отмечено, что HRlink не направляет в ИС запросов, а только отвечает на запрос.

Для того, чтобы Клиент мог организовать на стороне свой ИС контроль состояния подписания - необходимо реализовать циклический опрос HRlink по данным документов



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

Примечания

1

1) Кадровик запрашивает список документов с учётом фильтров

Status
subtletrue
colourYellow
titleGdoc

 POST

2. Кадровик редактирует параметры черновика

Предусловие - документ создан, но не был отправлен

Цель - внести изменения в метаданные документа:

  • тип, номер, дата

  • актуализировать состав участников

1) Кадровик вносит исправления в данные черновика документа

PUT

/api/v1/clients/:clientId/

documentGroups

Обновление происходит только внутри группы документов

2) используется один из описанных сценариев инициирования КЭДО

3. Кадровик заменяет Черновик

4. Кадровик заменят документ, находящийся на подписании

Цель - заменить файл документа или внести исправления в документ находящийся на подписании

documents/hrRegistry 

Получение реестра документов позволяет реализовать на стороне клиента опрос по документам, подходящим под набор условий:

(warning) При работе с реестрами важно учитывать [Пагинацию]

2

2) Кадровик запрашивает документ по ID своей ИС

Status
subtletrue
colourYellow
titleGdoc

 GET /api/v1/

1) Кадровик удаляет документ по ID документа в HRL

DELETE /api/v1/

clients/:clientId/documents/:

documentId

externalId/externalId 

или

удаляет список документов
своей ИС или ID в HRL

  • HRL

    Status
    subtletrue
    colourYellow
    titleGdoc

 GET

DELETE

/api/v1/clients/:clientId/documents

При необходимости удалить 1 документ по идентификатору из своей ИС, нужно использовать метод удаления группы документов и в теле запроса передать список из одного документа с указанием идентификатора своей ИС

/:documentId 

Альтернативой получения списка документов является запрос состояния конкретного документа по его идентификатору.

(warning) важно учитывать [Архитектурные особенности объекта] Документ


Отправка повторного уведомления 

Tip
titleЦель


Побудить к подписанию Сотрудника, на ком "завис" документ.


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

У Клиента есть идентификатор документа

2) Кадровик затирает ID своей ИС в удаленном документе

PUT /api/v1/clients/:clientId/documents/:externalId/externalId/clearExternalId

3) Используется один из подходящих сценариев инициирования КЭДО

5. Кадровик выгружает архив КЭДО

Цель - реализовать выгрузку архивов КЭДО

  • для бекапирования

  • для наполнения своей ИС архивами

1) Кадровик получает список документов с соответствии с фильтрами


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

Примечания

1

2) Кадровик инициирует повторное уведомление по документу

Status
subtletrue
colourRed
titleaddon

 

POST /api/v1/clients/:clientId/documents/signers/next/

hrRegistry

Данный шаг нужен для того, чтобы получить список документов, по которым требуется выгрузка архивов, однако если при создании документов используются идентификаторы своей системы, и список документов полностью управляется на стороне ИС Клиента, то данный шаг можно пропустить

notify 

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

Expand
titleПояснения к методу повторного уведомления

 POST

2) Кадровик скачивает архив КЭДО по ID документа своей ИС

GET

/api/v1/clients/:clientId/documents/

:externalId

signers/

externalId

next/

archive

notify 

или

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

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

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

Info

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

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

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

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

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

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

Info

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

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

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

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

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

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

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

Expand
titleПример файла шаблона заявления

View file
nameШаблон заявления (пример).docx
height150

Сценарий

Действия и 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

Тело запроса

Markdown
```
{
    "documentIds": [...]
}
```

(warning)  допускается только указание UUID идентификаторов HRlink

Валидации:

  • ID клиента должен соответствовать формату UUID
  • Клиент с заданным ID должен существовать
  • Текущий пользователь должен относиться к клиенту
  • Тело запроса должно быть задано
  • В теле запроса должен быть задан список ID документов
  • Документы с заданными ID должны существовать
  • Документы должны относиться к заданному клиенту
  • Документы должны быть не удалены
  • Документы должны быть не черновиками
  • Текущий пользователь должен иметь право на отправку уведомления следующему подписанту для каждого из документов DOCUMENTS_SEND_TO_SIGNING (на уровне пользователя или сотрудника)
  • По всем документам не должно быть подписантов, которые отказались подписывать
  • У каждого из документов должны быть следующие подписанты
  • Лимит СМС в пакете лицензий не должен быть исчерпан
  • Активный этап маршрута подписания каждого из документов может быть завершён, даже если на этапе есть уволенные подписанты

Ответ

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


(warning) вместо использования данного метода можно в ЛК настроить параметры автоуведомлений, для этого необходимо связаться с персональным менеджером.


Добавления примечания к документу

Tip
titleЦель


Добавить дополнительную информацию к документу

  • видимую только кадровикам
  • видимую всем участника КЭДО


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

У Клиента есть идентификатор документа


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

Примечания

1

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

Status
subtletrue
colourRed
titleaddon

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

 (warning)  примечание оставленное данным методом будет видно только Кадровикам.

Expand
titleПояснения к методу добавления примечания Кадровика

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

Тело запроса

Markdown
```
{
    "notice": "заметка кадровика",
	"version": 1
}
```

Валидации

  • ID клиента должен соответствовать формату UUID
  • ID документа должен соответствовать формату UUID
  • Тело запроса задано
  • Клиент с заданным ID должен существовать
  • Текущий пользователь должен относиться к клиенту
  • Документ с заданным ID должен существовать
  • Документ должен относиться к заданному клиенту
  • Если в теле запроса указана версия документа, то она должна быть указана корректно
  • У текущего пользователя должно быть право изменять заметку кадровика о документе DOCUMENTS_UPDATE

Ответ

Markdown
```
{
    "result": true,
	"document": {
		"notice": "заметка кадровика"
	}
}
```
2

2) Кадровик добавляет комментарий к документу, видимый всем участникам

Status
subtletrue
colourRed
titleaddon

 POST /api/v1/clients/:clientId/documents/:documentId/comments 

 

(warning) примечания оставленные данным методом будут видны всем пользователям, которые видят документ и использую ЛК HRlink

Image Added

Expand
titleПояснения к методу добавления общего комментария

 POST /api/v1/clients/:clientId/documents/:documentId/comments 

Тело запроса

Markdown
```
{
    "message": "Тестовый комментарий",
	"version": 1
}
```

Ответ

Markdown
```
{
    "result": true,
    "comment": {
        "id": "6cc81135-6318-442e-907f-83dbb4f9a9aa",
        "version": 1,
        "user": {
            "lastName": "Шелест",
            "firstName": "Леонид",
            "patronymic": null,
            "userId": "240a8b5e-9e2e-42a7-8977-160da4be05db"
        },
        "message": "тестовый комментарий",
        "createdDate": "2023-12-12T17:56:29.951576Z"
    }
}
```


Получение файлов, связанных с документом

Tip
titleЦель


Для разных целей можно использовать разные файлы КЭДО:

  • отображение документа с отметкой о подписании - печатная форма
  • для подписания файла УКЭП - сконвертированный файл
  • для дополнительного бекапирования - архив КЭДО
    • (warning)  HRlink для дополнительного бекапирования может предложить использование функционала выгрузки на SFTP сервер клиента.


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

У Клиента есть идентификатор документа


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

Примечания

1

1) Кадровик получает печатную форму документа с оттисками

Status
subtletrue
colourYellow
titleGdoc

 GET

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

documents/:documentId/printFormFile 

(info) печатная форма входит в архив КЭДО

2

2) Кадровик запрашивает файл, который подписывается в HRlink  

Status
subtletrue
colourYellow
titleGdoc

 GET

4. Кадровик получает все данные по Заявлениям с учётом всех фильтров

Цель - получить список заявлений по произвольному набору фильтров

POST

/api/v1/clients/:clientId/documents/

applicationGroups

:documentId/

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

  • файл, который подписан

convertedFile 

(info) сконвертированный файл входит в архив КЭДО

(warning) в случае, если процессы клиента предполагают подписание файла в нескольких системах, нужно учитывать, что в HRlink файл в документе - конвертируется и подписание происходит над сконвертированным файлом. 

3

3) Кадровик скачивает архив КЭДО по ID документа своей ИС

Status
subtletrue
colourYellow
titleGdoc

 

GET /api/v1/clients/:clientId/

applications

documents/:

applicationId/convertedFile

GET /api/v1/clients/:clientId/applications/:applicationId/archive

Печатная форма заявления может быть использована для отображения.

В случае, если Кадровику достаточно метаданных, полученных из заявления, то шаг с получением файла заявления можно пропустить

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

6. Кадровик обрабатывает Заявление

Предусловие - по одному из сценариев выше есть идентификатор заявления

  • кадровик получает реестр заявлений, ожидающих обработки Кадровиком

1) Кадровик берёт заявление в работу

externalId/externalId/archive 

или

 GET

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

/documents/:documentId/archive 

Архив КЭДО включает в себя:

  1. Сконвертированный файл, который подписывался
  2. Печатная Форма (ПФ) с оттиском электронной подписи
  3. Описание электронного документа XML файл
  4. Протокол КЭДО (входит в архив, только если его скачивает Кадровый специалист)
  5. Файлы подписей - может быть 1 или несколько файлов. Файл подписи ПЭП Госуслуги представлен в виде zip архива.

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

02. Кадровик. Основные процессы: Управление Персоналом

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

04. Кадровик. Основные процессы: Обработка Заявлений

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

Livesearch
spaceKeyWIKI
sizelarge