При разработке отчетов или доработке механизмов в конфигурации 1С:Зарплата и управление персоналом 3.1 программисты часто сталкиваются с необходимостью получить данные об отработанном времени (Факт) и норме времени по графику (План). Использование прямых запросов к регистрам накопления ДанныеТабельногоУчета или регистрам сведений ДанныеГрафиковРаботы считается плохим тоном и может привести к ошибкам, так как не учитывает сложные механизмы пересчетов, исправлений и вытеснений, заложенные в логику системы.
Рассмотрим, как правильно извлекать эти данные, используя встроенный программный интерфейс (API), который предлагает сама платформа и типовое решение. Мы разберем подходы, основанные на формировании временных таблиц, и проанализируем, какие программные модули за это отвечают.
Многие начинающие разработчики пытаются использовать функцию КадровыйУчет.КадровыеДанныеСотрудников. Однако важно понимать, что этот механизм предназначен для получения свойств сотрудника: ФИО, должности, подразделения, паспортных данных и т.д. Данные о времени — это динамические расчетные показатели, которые зависят от множества факторов (производственный календарь, индивидуальные графики, документы-отклонения). Поэтому для работы со временем в ЗУП 3.1 принята концепция «Временных таблиц в одном запросе».
Проанализируем работу с общим модулем УчетВремени. Это основной инструмент для работы с фактически отработанным временем. Если нам нужно получить данные о явках, ночных часах или сверхурочных, мы должны обратиться к процедурам, которые подготавливают временные таблицы для последующего использования в нашем запросе.
Рассмотрим процедуру СоздатьВТДанныеУчетаВремениСотрудников. Она позволяет системе самостоятельно собрать данные из всех источников (Табели, графики, первичные документы) и поместить их в таблицу, которую мы сможем прочитать. Типовой алгоритм выглядит следующим образом:
Выясним, как это выглядит в коде. Пример обращения к программному интерфейсу:
// Описываем параметры получения данных
ПараметрыПолученияДанных = УчетВремени.ПараметрыДляСоздатьВТДанныеУчетаВремениСотрудников();
ПараметрыПолученияДанных.Период = ПериодРегистрации;
ПараметрыПолученияДанных.Сотрудники = СписокСотрудников;
// Вызываем формирование ВТ во временном хранилище запроса
УчетВремени.СоздатьВТДанныеУчетаВремениСотрудников(Запрос.МенеджерВременныхТаблиц, Истина, ПараметрыПолученияДанных);
После выполнения этого кода в менеджере временных таблиц появится таблица (обычно с именем ВТДанныеУчетаВремениСотрудников), содержащая поля П1, П2 и другие, соответствующие различным видам времени, а также общее количество дней и часов.
Для получения планового времени (нормативных показателей) в системе существуют отдельные механизмы. План — это то, сколько сотрудник должен был отработать согласно своему основному или индивидуальному графику работы. Посмотрим на процедуру СоздатьВТДанныеГрафиковРаботы, которая находится в модуле РасчетЗарплатыРасширенный (или в модуле УправлениеВременем, в зависимости от версии релиза).
Эта процедура формирует временную таблицу, в которую записываются данные из графиков работы сотрудников. Это и есть та самая «Норма», которую мы ищем. Проанализируем процесс ее создания:
Пример программного вызова для создания таблицы графиков:
ПараметрыГрафиков = РасчетЗарплатыРасширенный.ПараметрыДляСоздатьВТДанныеГрафиковРаботы();
ПараметрыГрафиков.Период = НужныйПериод;
ПараметрыГрафиков.Сотрудники = МассивСотрудников;
РасчетЗарплатыРасширенный.СоздатьВТДанныеГрафиковРаботы(Запрос.МенеджерВременныхТаблиц, Истина, ПараметрыГрафиков);
Использование таких методов гарантирует, что вы получите актуальную информацию, даже если в середине месяца у сотрудника сменился график или был введен индивидуальный график работы.
Если ваша задача — получить не просто часы, а конкретные показатели, такие как ВремяВДнях или НормаДней, которые используются непосредственно в формулах начислений, разберем самый мощный инструмент — МенеджерРасчетаЗарплаты.
Этот объект позволяет имитировать процесс подготовки данных для расчета зарплаты. Он собирает все возможные данные: и графики (план), и фактически отработанное время, и показатели для формул. Рассмотрим последовательность действий при работе с менеджером:
МенеджерРасчетаЗарплаты.ПодготовитьДанныеДляРасчета.Посмотрим на пример логики:
Менеджер = РасчетЗарплатыРасширенный.СоздатьМенеджерРасчетаЗарплаты(МесяцНачисления, Организация);
// Настраиваем выборку сотрудников
// ...
Менеджер.ПодготовитьДанныеДляРасчета();
// Теперь данные доступны во временных таблицах менеджера
Важный нюанс: показатели ВремяВДнях и НормаДней физически рассчитываются системой в момент проведения документов начисления. Если вам нужно получить их «на лету» для отчета, менеджер расчета — это наиболее надежный способ, так как он «прогоняет» ту же логику, что и документ Начисление зарплаты и взносов.
Разберем, как объединить полученные данные. После того как вы вызвали процедуры создания временных таблиц для плана и факта, вы можете написать свой запрос, который соединит эти таблицы. Посмотрим на структуру такого запроса:
ВЫБРАТЬ
ДанныеФакта.Сотрудник,
ДанныеФакта.Часы КАК ФактЧасов,
ДанныеПлана.Часы КАК ПланЧасов
ИЗ
ВТДанныеУчетаВремениСотрудников КАК ДанныеФакта
ВНУТРЕННЕЕ СОЕДИНЕНИЕ
ВТДанныеГрафиковРаботы КАК ДанныеПлана
ПО
ДанныеФакта.Сотрудник = ДанныеПлана.Сотрудник
И ДанныеФакта.Дата = ДанныеПлана.Дата
Этот подход считается эталонным в архитектуре 1С:ЗУП 3.1. Мы не «изобретаем велосипед», пытаясь учесть все регистры, а используем готовые «кирпичики», которые предоставляет нам система. Это обеспечивает стабильность работы вашего кода при обновлениях конфигурации, так как логика сбора данных внутри общих модулей поддерживается разработчиками фирмы «1С».
Подведем итог нашему анализу инструментов получения времени:
УчетВремени.СоздатьВТДанныеУчетаВремениСотрудников.РасчетЗарплатыРасширенный.СоздатьВТДанныеГрафиковРаботы.МенеджерРасчетаЗарплаты.Помните, что работа с временными таблицами требует наличия у запроса МенеджерВременныхТаблиц. Всегда проверяйте, чтобы период и список сотрудников были корректно заполнены перед вызовом процедур API, чтобы избежать избыточной нагрузки на сервер базы данных.