В данном разделе есть описание объектов (метдананые, связи со справочниками или между собой, область видимости и определение состояния на основании признаков)

  • Справочники
    • Юрлицо
    • Отдел
    • Должность
    • Физлицо
    • Сотрудник
    • Тип документа
    • Вид Заявления
    • МЧД
  • Документ
  • Заявление
  • ЛНА


Общая модельная картина

Направление обмена информацией между системами

 

  1. Информационная Система Клиента (ИСК) передает в HRlink справочники

  2. Информационная Система Клиента (ИСК) передает в HRlink документы для КЭДО

    1. Оригинальный файл, в соответствии с ограничениями по типу и размеру

    2. Метаданные: Данные подписантов, идентификатор, данные документа

  3. Информационная Система Клиента (ИСК) запрашивает обновление состояния документа из HRlink

    1. Обновление статуса КЭДО

    2. Обновление по файлам: Архив КЭДО, ПФ с оттиском, Файлы подписей

Логические связи. Роли, Справочники, Виды подписей

  1. Логин, Пароль, Канал Уведомления, Электронная Подпись - это всё атрибуты ФЛ

  2. У одного ФЛ может быть множество Сотрудников
    1. Сотрудники могут обладать определённой ролью
    2. Сотрудники связаны с юрлицом (обязательно), отделом и должностью.

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

  1. Кадровик видит всех Руководителе (сотрудников, которые обладают ролью “Руководитель”)

  2. Кадровик видит Сотрудников (речь о тех, кто без роли руководитель) на основании единовременного выполнения следующих условий:

    1. Сотруднику назначен Отдел, который входит в список доступных для Кадровика отделов (или не привязан ни к одному отделу)

    2. Сотруднику оформлен в ЮЛ, которое соответствует Кадровику

      1. Пользователь Кадровый специалист обладает Сотрудником в Юрлице и у этого сотрудника есть роль Кадровик.

      2. Кадровику было выдано разрешение на выполнение кадровых процессов в рамках Юрлица.


Справочники

Для Интеграции HRlink предоставляет доступ к API в рамках тенанта Клиента.

Юрлицо

Юрлицо имеет следующий набор данных:

  1.  Наименование
    1. Полное
    2. Краткое
  2. Идентификатор
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Юрлица в ИС Клиента, может быть передан при создании или обновлении
  3. Реквизиты
    1. ИНН
    2. ОГРН
    3. КПП
    4. Адрес регистрации и Регион
  4. Руководитель
    1. Данные о сотруднике, который будет использоваться при маршрутизации КЭДО и генерации Заявлений по шаблону
    2. Основание для полномочий

Отдел

Отдел помогает определять область видимости и маршрутизацию КЭДО. имеет следующий набор данных:

  1. Наименование
  2. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Отдела в ИС Клиента, может быть передан при создании или обновлении
    3. идентификатор родительского отдела
  3. Связь с юрлицом (необязательная) - через id HRlink
  4. Руководитель отдела (необязательный) - используется для маршрутизации КЭДО

Должность

Имеет следующий набор данных:

  1. Наименование
  2. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Должности в ИС Клиента, может быть передан при создании или обновлении

Физлицо

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

  1. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Должности в ИС Клиента, может быть передан при создании или обновлении
  2. Данные ФЛ:
    1. Фамилия, Имя, Отчество
    2. Пол
    3. Дата рождения
  3. Данные о документах: СНИЛС, ИНН, Паспорт
  4. Данные пользователя
    1. Логин
    2. Канал уведомления
    3. Данные приглашения
  5. Данные ЭП
    1. Данные о последнем запросе на выпуск УНЭП
    2. Данные о текущей ЭП, доступной пользователю
  6. Связь с Сотрудниками

(warning)  Роль Администратора может быть назначена на Физлицо.

Сотрудник

имеет следующий набор данных:

  1. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Должности в ИС Клиента, может быть передан при создании или обновлении
    3. Табельный номер - строгая уникальность в рамках юрлица
  2. Связь с Юрлицом (обязательно)
  3. Связь с Отделом
  4. Связь с Должностью
  5. Роли: Кадровика, Руководителя, Делопроизводителя, Кастомная роль
  6. Данные о дате увольнения: может не быть (сотрудник считается работающим), может быть задана как текущее или прошедшее число (сотрудник уже уволен) и быть задана как будущая дата (например, отработка при увольнении)
  7. Теги - для произвольного группирования 

Тип документа

имеет следующий набор данных:

  1. Наименование
  2. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Должности в ИС Клиента, может быть передан при создании или обновлении
  3. Код классификатора Минтруда
  4. Признаки:
    1. Видимости - активный или скрыт
    2. Системный или Кастомный

Вид Заявления

имеет следующий набор данных:

  1. Наименование
  2. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Должности в ИС Клиента, может быть передан при создании или обновлении
  3. Признак видимости - активен шаблон заявления или нет
  4. Данные шаблона
    1. Файл шаблона
    2. Набор полей используемых в шаблоне (системных и пользовательских)
    3. Данные маршрута прохождения Заявления
    4. Переопределение шаблона для Юрлица

МЧД (Машино Читаемая Доверенность)

Обязательность использования МЧД может быть включена как настройка Тенанта у Клиента. МЧД определяет возможность подписания документов УКЭП от лица Работодателя.

Имеет следующий набор данных:

  1. Номер, Дату выдачи, Срок действия
  2. Связь с Юрлицом
  3. Идентификаторы
    1. ID - UUID генерируемый HRlink автоматически, обязательно уникален в рамках тенанта
    2. externalID - идентификатор Должности в ИС Клиента, может быть передан при создании или обновлении
  4. Полномочия

Документ

Документом в HRlink называется объект, у которого КЭДО направлен от Работодателя к Работнику, т.е. по сути Кадровик Направляет Документ на Подписание.


Общая схема работы с Документом

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

  1. Автором документа может быть только Кадровик

  2. В документе могут быть следующие роли:

    1. Кадровик - автор документа, тот кто может получить состояние документа в любой момент времени (при условии наличия достаточных прав для просмотра документа)

    2. Подписант

      1. Представитель Работодателя - пользователь, который подписывает документ от имени работодателя

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

    3. Наблюдатель - пользователь, который может ознакомиться с документом без подписания только после того, как КЭДО завершен

  3. Видимость документа для Подписантов определяется

    1. Прямым указанием Пользователя как участника КЭДО

    2. Маршрутом документа и его состоянием

      1. Т.е. если документ сперва должен подписать Руководитель и только потом - Сотрудник, то

        1. Руководитель его видит сразу после того, как Документ направлен на подписание,

        2. Сотрудник видит только после того, как Руководитель подписал документ

  4. Любой участник КЭДО может скачать Архив КЭДО по видимому документу

 Условия видимости документа

  1. Документ может создать только Кадровик и может указать в нём:
    1. Тип документа - определяется из Справочника Типов документов, на основании того, какие Типы документов были разрешены Администратором для Кадровика
    2. ЮЛ - определяется на основании того, по каким ЮЛ у пользователя есть отрудник с ролью Кадровик или по 
    3. Подписанты

      1. В качестве Представителя работодателя, Кадровик может указать любого действующего сотрудника, с ролью Руководитель

      2. В качестве Сотрудника/Наблюдателя, Кадровик может указать только тех Пользователей, у которых сотрудники входя в доступные Отделы, разращённые Администратором

    4. Маршрут подписания

  2. Кадровик видит документ только на основании соответствия - Типа документа, Подписантов (хотя бы один должен входить в разрешённый отдел) и ЮЛ

    1. Кадровик видит документ без учёта состояния документа и маршрута подписания

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

  4. Наблюдатели могут видеть только те документы, в которых были указаны и только по документам у которых завершен КЭДО

  5. Если документ имеет связь с другим Документом/Заявлением - то тот, кто видит Документ со связью может увидеть и тот объект, с которым связь установлена.
    1. Например, Приказ о выплате создан на основании Заявления о компенсации. Руководитель подписывающий Приказ не был участником КЭДО в Заявлении, но так как Приказ связан с Заявлением, то раз Руководитель видит Приказ, видит связь, то сможет увидеть и Заявление.


Архитектурные особенности объекта

Очень важно учитывать поведение документов при отправке с точки зрения externalId (идентификатора в ИС Клиента)

  • В ряде случаев externalId, указанный при создании, будет сохранён в поле externalId
  • В ряде случаев externalId, указанный при создании, перейдёт в поле baseDocumentExternalId
  • Частичная отправка на подписание не возможна, если при создании был указана externalId
  1. При создании документа всегда формируется ГРУППА ДОКУМЕНТОВ, в которой может быть 1 или несколько документов.
  2. При создании документа ему кроме метаданных нужен файл, который будет подписываться, но нужно учесть процедуру конвертации
    1. Если при создании был передан идентификатор загружаемого файла - то файл будет сконвертирован в PDF/A, т.е. файл который будет участвовать в подписании отличен от того файла, который был загружен.
    2. Если при создании был передан идентификатор другого документа, прошедшего конвертацию, то будет использоваться сконвертированный ранее файл
  3. Всегда создаётся объект - ЧЕРНОВИК ДОКУМЕНТА
    1. после отправки он получает отметку, что был отправлен и имеет признак, что является черновиком. Исключён из выдачи документов в реестре документов.
  4. Если в документе более 1 Сотрудника (именно Сотрудника, не Участника), то при отправке документ будет размножен.
    1. Все размноженные документы будут связаны с ЧЕРНОВИКОМ
    2. Если отправка частичная, то дополнительно формируется ПРОМЕЖУТОЧНЫЙ ЧЕРНОВИК, в котором данные только по тем, кому отправить документ не было возможным. Когда последнему участнику промежуточного черновика будет отправлен документ, промежуточный черновик будет удалён.
  5. При создании документа, HRlink формирует (ЧЕРНОВИК) с уникальным идентификатором, если при создании (ЧЕРНОВИКА) был передан externalId, то
    1. Не может существовать двух документов с одним и тем же externalId. Если уже есть черновик с задействованным идентификатором - это заблокирует создание нового с таким же идентификатором.
    2. Сохранение externalId зависит от размножения:
      1. Если документ размножается, то externalId переходит в поле baseDocumentExternalId
      2. Если документ не размножается (т.е. там 1 или 0 сотрудников), то externalId из ЧЕРНОВИКА удаляется и передаётся как externalId в Документ, который формируется при отправке.
    3. Так как не может быть 2х документов с одним идентификатором и при частичной отправке формируется ПРОМЕЖУТОЧНЫЙ черновик - в случае использования externalId метод частичной отправки не будет работать.

Метаданные и связи

Описание атрибутов документа при создании подробно указаны в API-методе создания

Описание атрибутов документа при получении данных документа подробно указаны в API-методе получения данных документа

Документ имеет связи с некоторым множеством файлов:

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

Определение состояния и видимость

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

СостояниеАтрибут и значениеКомментарий
Черновик

document.draft = true

document.baseDocumentId = null

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

document.draft = false

document.deleted = false

document.docflowFinishedDate = null

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

document.lastSignedDate - дата и время последнего подписания

document.printFormUpdatedDate - дата и время последнего обновления Печатной Формы (ПФ). Если меньше чем дата последнего подписания, то ПФ ещё не содержит в оттиске данных о последнем подписании.

Завершён успешно

document.docflowFinishedDate != null

document.signed = true

document.deleted = false

 Документ у которого есть дата завершения КЭДО и есть признак о наличии всех подписей и нет отметки об удалении - можно считать документом с успешно завершённым КЭДО
Завершён отклонением

document.docflowFinishedDate != null

document.rejected = true

Если у документа есть дата завершения и есть отметка об отклонении - то КЭДО по документу завершён отклонением.
Удалёнdocument.deleted = trueдокумент может быть удалён в произвольный момент: черновик может быть удалён, документ в процессе может быть удалён, документ отклонённый или даже успешно подписанный - может быть удалён.

Заявление

Заявлением в HRlink называется объект, у которого КЭДО направлен от Работника к Работодателю, т.е. по сути Сотрудник Направляет Заявление на Обработку.

Общая схема работы с Заявлением

Действия доступные над Заявлением

Метаданные и связи

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

Например, в шаблоне заявления на отпуск могут быть кастомные поля "Дата начал отпуска" и "Количество дней отпуска", а в "Заявлении на компенсацию таких полей не будет, зато будет кастомное поле с суммой компенсации.


Определение состояния

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

СостояниеАтрибут и значениеКомментарий
Черновик


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

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

Ожидает решения согласующего

Нужно взять в работу

Определён ответственный

applicationGroup.applications[].docflowFinishedDate = null

  • applicationGroup.applications[].lastSignedDate
  • applicationGroup.applications[].printFormUpdatedDate

applicationGroup.applications[].deletedDate = null

applicationGroup.applications[].rejectedDate = null

Все три состояния относятся к одному - "В процессе", т.е. есть такой участник, от которого ожидается совершения какого-то действия

  • lastSignedDate - показывает когда было совершено последнее действие над заявлением
  • printFormUpdatedDate = когда была последний раз обновлена ПФ, если меньше даты и времени последнего действия, то ПФ ещё не обновилась

Чтобы понять, на ком именном сейчас заявление находится в работе, надо разбирать данные в полях

  • applicationGroup.applications[].signers[]:
    • _.signingAvailabilityDate - дата и время, когда Заявление доступно к обработке участнику
    • _.madeDecision - true/false принято или нет решение по заявлению
    • _.signedDate - дата и время обработки заявления
    • _.rejectedDate - дата и время отклонения
  • описание этапов прохождения заявления => applicationGroup.applications[].route.stages
Обработано

applicationGroup.signedDate != null

applicationGroup.applications[].docflowFinishedDate != null

Если у Заявления есть дата и время завершения КЭДО и при этом нет отметок об отклонении или удалении - обработка заявления успешно завершена.
Отклонено

applicationGroup.applications[].rejectedDate != null

applicationGroup.applications[].docflowFinishedDate != null

Если у Заявления есть дата и время завершения КЭДО и есть отметка времени об отклонении - то обработка заявления завершена отклонением.
УдаленоapplicationGroup.applications[].deletedDate != nullЕсли у Заявления есть дата и время удаления, значит обработка заявления завершена решением Заявителя об удалении Заявления.

ЛНА

ЛНА - такой тип документа, который предполагает возможность динамического определения подписантов.

Т.е. Кадровик может создать ЛНА, а HRlink постоянно проверяет кому из Сотрудников (на основании ЮЛ, Отдела, Должности и Триггерного события) должен быть направлен ЛНА на ознакомление

Архитектурные особенности объекта

  1. ЛНА это не документ, а отдельный объект.
  2. ЛНА может проходить цепочку с согласованием, тогда в нём появится УКЭП Представителя Работодателя, но может быть направлен на ознакомление Сотрудникам без согласования.
  3. Сотруднику на ознакомление приходит объект Документ (который формирует HRlink автоматически при выполнении всех условий)
  4. Сотрудник не может отклонить Документ ЛНА
  5. Лист Ознакомления у ЛНА фактически это вычисляемое состояние на основании всех связанных Документов ЛНА
  6. Состояние ЛНА "завершено" фактически не является терминальным, при появлении необходимости ознакомить нового сотрудника - ЛНА перейдёт в состояние "В работе" автоматически.
  7. При удалении ЛНА будут удалены и все неподписанные Документы ЛНА

Общая схема работы с ЛНА

Определение состояния

На схеме представлено общая логическая модель состояний, однако явным образом статуса в ЛНА - нет, есть набор атрибутов, которые позволяют определить состояние.

СостояниеАтрибут и значениеКомментарий
Черновик

normativeAct.fileConversionFailedDate = null

normativeAct.sentDate = null

Нет отметки времени об ошибке конвертации

нет даты отправки ЛНА

Отправляется на подписание

normativeAct.sendToSigningTasks != []

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

В процессе

normativeAct.sentDate != null

normativeAct.autoSendEnabled = true

Период действия ЛНА:

  • normativeAct.startDate < текущей даты  
  • normativeAct.endDate > текущей даты

Есть дата отправки

Важным может быть понимание - включена автооотправка или нет.

На верхнем уровне понимание процесса можно получить из двух цифр:

  • normativeAct.signingInfo.totalCount - Всего сотрудников на подписания ЛНА
  • normativeAct.signingInfo.currentCount - Текущее число сотрудников подписания ЛНА

ЛНА может обладать сроком действия в виде диапазона даты начала и даты завершения, тогда надо сравнивать границы с текущей датой

Подписан

normativeAct.deletedDate = null

normativeAct.sentDate != null

Счётчик подписания

  • normativeAct.signingInfo.totalCount - Всего сотрудников на подписания ЛНА
  • normativeAct.signingInfo.currentCount - Текущее число сотрудников подписания ЛНА
в целом аналогично состоянию "В процессе", но счётчики должны сойтись на одном числе.
УдаленоnormativeAct.deletedDate != null

есть отметка времени удаления ЛНА

ОшибкаnormativeAct.fileConversionFailedDate != nullесть отметка времени возникновения ошибки конвертации

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