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