Как правильно вычислить факт увольнения сотрудника в 1С:ЗУП 3.1?

Программист 1С v8.3 (Управляемые формы) 1С:Зарплата и Управление Персоналом IT и автоматизация бизнеса
← На главную

Часто при разработке дополнительных отчетов, обработок или расширений в конфигурации 1С:Зарплата и Управление Персоналом (ЗУП) возникает базовая, на первый взгляд, задача — определить, уволен ли сотрудник на определенную дату. Давайте подробно разберем и проанализируем различные подходы к решению этой задачи, выясним, из каких регистров правильнее брать информацию и почему использование программного интерфейса считается наиболее надежным вариантом.

Способ 1: Получение данных прямым запросом к регистру кадровой истории

Если нам нужно быстро проверить информацию в консоли запросов или написать простую выборку, мы можем обратиться напрямую к регистру сведений КадроваяИсторияСотрудников. Рассмотрим пример запроса, который выбирает уволенных сотрудников:


ВЫБРАТЬ
    КадроваяИсторияСотрудниковСрезПоследних.Сотрудник КАК Сотрудник,
    КадроваяИсторияСотрудниковСрезПоследних.Должность КАК Должность,
    КадроваяИсторияСотрудниковСрезПоследних.Организация КАК Организация
ИЗ
    РегистрСведений.КадроваяИсторияСотрудников.СрезПоследних(&КонецПериода, ) КАК КадроваяИсторияСотрудниковСрезПоследних
ГДЕ
    КадроваяИсторияСотрудниковСрезПоследних.ВидСобытия = ЗНАЧЕНИЕ(Перечисление.ВидыКадровыхСобытий.Увольнение)

Нюансы данного метода:

  1. Мы используем виртуальную таблицу СрезПоследних на переданную дату КонецПериода, чтобы получить актуальное кадровое состояние.
  2. Проверка осуществляется по полю ВидСобытия, которое сравнивается со значением перечисления ВидыКадровыхСобытий.Увольнение.
  3. Этот способ отлично подходит для разовых выборок в консоли, однако для интеграции в промышленный код он считается не самым надежным из-за возможных изменений структуры регистров в новых релизах 1С.

Способ 2: Использование программного интерфейса (API) 1С:ЗУП

Как показывает практика и рекомендации разработчиков, более корректный и надежный путь — обращение к специализированному программному интерфейсу (API). Разберем по шагам, как получить дату увольнения через экспортные функции общих модулей. Это защитит ваш код от поломок при обновлениях конфигурации, так как 1С поддерживает обратную совместимость общих модулей.

Рассмотрим пример кода:


ТаблицаКадровыхДанных = КадровыйУчет.КадровыеДанныеСотрудников(
    Истина, // Получаем только разрешенные данные (с учетом прав доступа)
    ОбщегоНазначения.ЗначениеВМассиве(Сотрудник), // Массив ссылок на сотрудников
    "ДатаУвольнения", // Имя поля получаемых кадровых данных
    ДатаПолученияДанных // Дата, на которую запрашиваем информацию
);

В полученной таблице значений ТаблицаКадровыхДанных будет содержаться ссылка на сотрудника и его дата увольнения. Обратите внимание на важные проверки: возвращаемое значение может быть NULL, либо, если сотрудник еще работает, поле может содержать пустую дату (например, 01.01.0001). Поэтому при обработке результата обязательно используйте функцию ЗначениеЗаполнено() для корректной проверки.

Альтернативно, вместо поля ДатаУвольнения, мы можем запросить поле Состояние и сравнить его с состоянием увольнения:


// В запросе полей указываем "Состояние"
ТаблицаКадровыхДанных = КадровыйУчет.КадровыеДанныеСотрудников(Истина, МассивСотрудников, "Состояние", ДатаПолученияДанных);

Анализ служебных регистров: где на самом деле хранятся данные?

Посмотрим на внутреннюю архитектуру ЗУП 3.1. Дата приема и дата увольнения — это статические данные, независимые от шкалы времени. Для их хранения и быстрого извлечения предусмотрен специальный служебный регистр ТекущиеКадровыеДанныеСотрудников.

Проанализируем особенности этого регистра:

  1. Производительность: Регистр создан специально для быстрого вывода информации в динамические списки, например, в справочник "Сотрудники", минуя тяжелые соединения виртуальных таблиц.
  2. Доступность: Типовые механизмы и упомянутый выше программный интерфейс при запросе простых полей (таких как дата увольнения) под капотом обращаются именно к этому регистру.
  3. Риск рассинхронизации: При программных сбоях или ручных переносах данных информация в нем может "отстать" от реальных кадровых документов (например, приказ проведен, а дата в регистре пустая). В таком случае помогает простое перепроведение документа увольнения или использование встроенных утилит обновления кадровых данных.

Что касается регистра ДанныеСостоянияСотрудников, то он хранит периоды различных отклонений (Отпуск, Больничный, Прогул) и текущее состояние "Работает" или "Увольнение". Использовать его исключительно для проверки факта увольнения избыточно, так как он предназначен для корректного формирования табеля и начисления зарплаты. Запросы к нему сильно усложнят ваш код.

Ключевые методологические нюансы учета увольнений

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

1. "Будущие" увольнения:
Нередко кадровик оформляет приказ заранее. Например, 10-го числа вносится документ об увольнении, которое произойдет 25-го числа. Если мы сделаем срез последних записей регистра кадровой истории на 10-е число, система покажет, что сотрудник еще работает. Однако, если мы используем функцию КадровыеДанныеСотрудников или обратимся к регистру ТекущиеКадровыеДанныеСотрудников, мы сразу получим заполненную "Дату увольнения", так как этот факт уже зафиксирован в системе статично.

2. Совместительство (Сотрудник vs Физическое лицо):
В ЗУП 3.1 четко разделены понятия. Одно физическое лицо может иметь несколько рабочих мест, каждому из которых соответствует свой элемент справочника "Сотрудники" (например, основное место работы и внутреннее совместительство). Вычисление факта увольнения всегда необходимо производить в разрезе конкретного элемента справочника "Сотрудники". Тот факт, что одно из совместительств закрыто (один сотрудник уволен), не означает, что предприятие полностью прекратило трудовые отношения с данным физическим лицом.

← На главную