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

Compare with Current View Page History

« Previous Version 7 Next »

О чём раздел

Под управлением структурой подразумевается:

  1. Юрлица - получение данных, внесение изменений

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

  2. Отделы/департаменты/подразделения - создание, обновление и получение данных

  3. Должности - создание, обновление и получение данных

  4. Типы кадровых документов - обновление и получение данных

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

  5. Типы заявлений - создание, обновление и получение данных

 

Основные сценарии управления структурой и Справочниками

Примечание

Важно

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

В ряде случае для Клиента наиболее простой путь интеграции (особенно если идёт интеграция только кадрового потока процессов, см. раздел [01. Подходы к интеграции]) - использование токена Администратора.

  • Поэтому можно считать, что все сценарии Кадрового специалиста применимы для Администратора.

Обновление данных Юрлица

Цель


Актуализация информации о Юрлица клиента.

В юрлице может быть задан руководитель имеющий право действовать без МЧД. Также данные данного руководителя (ФИО и Должность в дательном падеже) могут быть использованы для подстановки в шаблоны заявлений, если эти переменные указаны в файле шаблона заявления (на чьё имя подаётся заявление).


Предусловие

Администратор выгрузил справочник юрлиц → [01. Администратор. Базовые настройки справочников]

1

API-методы

Примечания

1

 GET /api/v1/clients/:clientId/legalEntities 

или

 PUT /api/v1/clients/:clientId/legalEntities/:legalEntityExternalId/externalId 

Данный шаг можно пропустить, т.к. он нужен только для получения списка идентификаторов, чтобы производить обновления по конкретному ЮЛ.

Кроме получения данных всего списка можно получить данные одного Юрлица.

2

 PUT /api/v2/clients/:clientId/legalEntities/:externalId/externalId 

или

 PUT /api/v1/clients/:clientId/legalEntities/:legalEntityId 

или

 PUT /api/v2/clients/:clientId/legalEntities/:legalEntityId 

или

 PUT /api/v1/clients/:clientId/legalEntities/:legalEntityId 

через поле externalId (Идентификатор ЮЛ в ИС Клиента)

Методы обновления v2 поддерживают возможность обновления большего количества параметров:

  • Цифровой код региона.
  • Данные руководителя юридического лица для создания.


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

3

1) Создать новую задачу массовой синхронизации данных   REDOC

 POST /api/v1/clients/:clientId/bulkDataSyncTasks 

2) Получить статус задачи массовой синхронизации данных по идентификатору задачи REDOC

 GET /api/v1/clients/:clientId/bulkDataSyncTasks/:taskId 

Если справочник юрлиц имеет большое количество юрлиц, то его обновление может быть осуществлено с помощью метода пакетной выгрузки.


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

(warning) только Администратор может используя данный метод осуществить первичную выгрузку юрлиц [01. Администратор. Базовые настройки справочников]

 

Управление справочником Отделов

Цель


Актуализация информации о действующих Отделах.

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

  1. управления областью видимости Кадровика → [03. Администратор. Настройка областей видимости для Кадровика]
  2. упрощения выбора сотрудников через отдел (важно для использования кадровиком ЛК HRlink)
  3. определения руководителя отдела, который будет подставляться в маршрут согласования Заявления



API-методы

Примечания

1

 GET /api/v1/clients/:clientId/departments 

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

2

 PUT /api/v1/clients/:clientId/departments/:externalId/externalId 

или

 PUT api/v1/clients/:clientId/departments/:departmentId 

или использовать пакетный метод, для выгрузки отделов

1) Создать новую задачу массовой синхронизации данных   REDOC

 POST /api/v1/clients/:clientId/bulkDataSyncTasks 

2) Получить статус задачи массовой синхронизации данных по идентификатору задачи REDOC

 GET /api/v1/clients/:clientId/bulkDataSyncTasks/:taskId 

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


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

3

 PUT /api/v1/clients/:clientId/departments/:externalId/externalId 

или

 PUT api/v1/clients/:clientId/departments/:departmentId 

Удаление рассматривается как частный случай обновления.


4

 DELETE /api/v1/clients/:clientId/departments/:departmentId 

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


Управление справочником Должностей

Цель


Актуализация информации о действующих должностях.

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

Однако Использование должностей в значительной степени влияет на использования функционала ЛНА.



API-методы

Примечания

1

  • Создание должности GDOC

 POST/api/v1/clients/:clientId/employeePositions 

или использовать пакетный метод, для выгрузки отделов

1) Создать новую задачу массовой синхронизации данных   REDOC

 POST /api/v1/clients/:clientId/bulkDataSyncTasks 

2) Получить статус задачи массовой синхронизации данных по идентификатору задачи REDOC

 GET /api/v1/clients/:clientId/bulkDataSyncTasks/:taskId 

Первичное наполнение справочника должностей может быть организовано или через использование пакетного метода выгрузки

Если справочник Должностей имеет большое количество должностей, то его создание и обновление может быть осуществлено с помощью метода пакетной выгрузки.


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

2

 GET /api/v1/clients/:clientId/employeePositions 

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

Также при точечном создании должности в ответ возвращается идентификатор должности

3

 PUT /api/v1/clients/:clientId/employeePositions/:externalId/externalId 

или

 PUT /api/v1/clients/:clientId/employeePositions/:positionId 

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

4

 DELETE /api/v1/clients/:clientId/employeePositions/:positionId 

(warning) Удаление происходит не через отметку об удалении, а через удаление объекта из базы данных, поэтому удаление Должности возможно только если нет ни одного сотрудника, привязанного к Должности.


Управление справочником Типов Документов

Цель


Тип документа - не является обязательным для создания документа, однако имеет большое значение в управлении ЛНА

и может быть связан с развитием функционала системы HRlink



API-методы

Примечания

1

 GET /api/v1/documentTypes 

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

Однако созданный Типы документов можно наполнить идентификаторами ИС Клиента и управлять видимостью типов документов.

2

 PUT /api/v1/documentTypes/:externalId/externalId 

 PUT /api/v1/documentTypes/:documentTypeId 

Для типов документов, созданных Администратором можно обновить все параметры.

(warning) Для типов документов HRlink (дефолтный справочник) можно изменять только видимость типа документа и extertnalId


Управление справочником Шаблонов Заявлений

Цель


Подготовить справочник Шаблонов Заявлений, которыми сможет воспользоваться Сотрудник при подаче Заявлений.

К подготовке можно отнести актуализацию - корректировку имён шаблонов и видимость для Сотрудника при подаче


Предусловие

Первичное создание шаблона заявления сейчас доступно только через обращение в Службу Заботы о Клиентах, дальнейшее использование и настройка - доступны как в ЛК, так и по API

Подробнее о заявлениях см. раздел Заявление


API-методы

Примечания

1

 GET /api/v1/applicationTypes 

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

Настройка шаблонов идёт с указанием идентификатора шаблона

(warning) В данных типа заявления возвращаются кастомные поля

2

 GET /api/v1/clients/:clientId/applicationTypes/:applicationTypeId/templateFile 

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

Клиент так же может задать собственное форматирование файла - шрифты, кегель, отступы и т.д.

Оформление шаблона происходит вне рамок информационных систем.

3

 GET /api/v1/applicationTypeFields/system 

Системные поля - это поля, которые предопределены HRlink и являются общими для всех типов заявлений.

(warning) Кроме системных полей есть ещё кастомные поля, которые определены для каждого заявления в отдельности. Получение их указано в первом методе сценария.

4

 POST /api/v1/files 

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

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

Для Каждого ЮЛ на один тип Заявления может быть задан собственный шаблон.

5

 PUT /api/v1/applicationTypes/:applicationTypeId 

При обновлении Кадровик

  • задаёт названия Шаблонов, используемых Клиентом,

  • привязывает идентификатор обновлённого шаблонного файла

  • задает видимость

  • задаёт какое поле с типом дата можно считать датой события
    • (warning) например, для типа заявления = "Заявление на отпуск" датой события можно считать дату начала отпуска. Дата, которая обозначена как дата события будет отображаться в ЛК в реестре Заявлений Кадровика. Также при получении данных заявления можно будет получить информацию о дате события, что позволит оптимизировать обработку разных типов заявлений, для которых важна какая-либо дата

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


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


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

  • No labels