Как правильно получить полную выборку данных по сотрудникам в УПП 1.3?

При разработке кадровых и зарплатных отчетов в конфигурации «1С:Управление производственным предприятием 1.3» часто возникает задача получить сводную выборку по сотрудникам со множеством связанных реквизитов: кадровой историей, банковскими реквизитами, свойствами и категориями. Разберем, как устроена структура хранения этих данных, какие типовые механизмы можно использовать для построения выборки, а также разберем типичные ошибки при написании собственных запросов.

Архитектура хранения кадровых данных в УПП 1.3

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

1. Справочник СотрудникиОрганизаций и справочник ФизическиеЛица. Кадровые сведения (должность, подразделение, график работы, табельный номер) ведутся в разрезе сотрудников. Персональные данные человека (паспортные данные, ИНН, СНИЛС, лицевые счета банковских карт) привязаны к физическому лицу. Если связывать кадровые данные исключительно через физическое лицо, при наличии внутренних совместителей произойдет дублирование строк и смешение данных разных трудовых договоров.
2. Кадровые срезы. Актуальное состояние сотрудника хранится в периодическом регистре сведений РаботникиОрганизаций.
3. Дополнительные реквизиты. Свойства и категории хранятся в регистрах сведений ЗначенияСвойствОбъектов и КатегорииОбъектов.

Типовые инструменты конфигурации для получения данных

В типовой конфигурации УПП 1.3 уже заложены отлаженные механизмы выборки сотрудников, которые учитывают все кадровые нюансы:

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

Разбор пользовательского запроса и частых ошибок

Посмотрим на пример запроса, который разработчики часто пытаются использовать для сбора максимального количества информации по сотруднику через временные таблицы:

ВЫБРАТЬ
    РаботникиОрганизацийСрезПервых.Период,
    РаботникиОрганизацийСрезПервых.Сотрудник.Физлицо КАК Физлицо,
    РаботникиОрганизацийСрезПервых.Организация
ПОМЕСТИТЬ ДатаПриема
ИЗ
    РегистрСведений.РаботникиОрганизаций.СрезПервых(, ) КАК РаботникиОрганизацийСрезПервых
;

ВЫБРАТЬ
    РаботникиОрганизацийСрезПоследних.Сотрудник.Физлицо КАК СотрудникФизлицо,
    РаботникиОрганизацийСрезПоследних.Организация КАК Организация,
    РаботникиОрганизацийСрезПоследних.Период КАК Период,
    РаботникиОрганизацийСрезПоследних.ПодразделениеОрганизации КАК ПодразделениеОрганизации,
    РаботникиОрганизацийСрезПоследних.Должность КАК Должность
ПОМЕСТИТЬ ФЛ
ИЗ
    РегистрСведений.РаботникиОрганизаций.СрезПоследних(&Период, ) КАК РаботникиОрганизацийСрезПоследних
;

ВЫБРАТЬ
    ЗначенияСвойствОбъектов.Объект,
    ЗначенияСвойствОбъектов.Значение КАК Значение
ПОМЕСТИТЬ БАНК
ИЗ
    РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
ГДЕ
    ЗначенияСвойствОбъектов.Свойство.Код = "00000000032"
;

ВЫБРАТЬ
    ЛицевыеСчетаРаботниковОрганизации.НомерЛицевогоСчета,
    ЛицевыеСчетаРаботниковОрганизации.ФизЛицо
ПОМЕСТИТЬ лс1
ИЗ
    РегистрСведений.ЛицевыеСчетаРаботниковОрганизации КАК ЛицевыеСчетаРаботниковОрганизации
ГДЕ
    ЛицевыеСчетаРаботниковОрганизации.Банк.Код = "000004647"
;

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ФЛ.СотрудникФизлицо КАК СотрудникФизлицо,
    ФЛ.Организация,
    ДатаПриема.Период КАК ДатаПриема,
    ФЛ.ПодразделениеОрганизации КАК ПодразделениеОрганизации,
    ФЛ.Должность,
    БАНК.Значение КАК Банк,
    лс1.НомерЛицевогоСчета КАК Промсвязьбанк
ИЗ
    ФЛ КАК ФЛ
    ЛЕВОЕ СОЕДИНЕНИЕ БАНК КАК БАНК
        ПО ФЛ.СотрудникФизлицо = БАНК.Объект
    ЛЕВОЕ СОЕДИНЕНИЕ ДатаПриема КАК ДатаПриема
        ПО ФЛ.СотрудникФизлицо = ДатаПриема.Физлицо
        И ФЛ.Организация = ДатаПриема.Организация
    ЛЕВОЕ СОЕДИНЕНИЕ лс1 КАК лс1
        ПО ФЛ.СотрудникФизлицо = лс1.ФизЛицо

Проанализируем скрытые проблемы и критические ошибки в таком подходе:

1. Недопустимость инструкции ДЛЯ ИЗМЕНЕНИЯ в отчетах. Если в запросе для выборки данных случайно остается конструкция ДЛЯ ИЗМЕНЕНИЯ, СУБД устанавливает блокировки на таблицы. В многопользовательской среде это приводит к блокировкам транзакций и ошибкам взаимной блокировки (Deadlock).
2. Ошибочное определение даты приёма через СрезПервых. Если сотрудник увольнялся и был принят на работу повторно, СрезПервых вернет дату самого первого приема за всю историю. Корректную дату текущего приема нужно определять по последней записи с видом события приема на работу, предшествующей периоду отчета.
3. Попадание уволенных сотрудников в срез. Виртуальная таблица СрезПоследних возвращает последнюю запись по сотруднику на указанную дату. Если сотрудник уволен, последней записью будет увольнение. Без явной проверки состояния или условия на количество занимаемых ставок в отчет попадут все уволенные работники компании.
4. Игнорирование полей завершения при временных переводах. В регистре РаботникиОрганизаций присутствуют реквизиты ПериодЗавершения, ДолжностьЗавершения и ПодразделениеОрганизацииЗавершения. Если сотрудник был переведен временно, и срок перевода истек, прямой СрезПоследних вернет временную должность вместо возврата на исходную позицию.
5. Жесткая привязка к кодам элементов справочников. Фильтрация свойств и банков по кодам вида "00000000032" или "000004647" крайне ненадежна. При переносе данных, тестировании на копии базы или перенумерации справочников такие фильтры перестают работать.
6. Избыточное создание временных таблиц. Создание десятков временных таблиц под каждое отдельное свойство из одного и того же регистра перегружает системную базу данных tempdb на SQL-сервере. При разработке отчета в СКД (Системе компоновки данных) свойства и категории эффективнее выводить через встроенный механизм Характеристик, без ручных соединений в тексте запроса.