You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Цель

...

Предусловие

...



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

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

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

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

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

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

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



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

  • No labels