← На главную

При работе с Системой компоновки данных (СКД) разработчики часто сталкиваются с ситуацией, когда необходимо получить ссылку на объект (например, справочник Должности или Сотрудники) с помощью функции общего модуля в вычисляемом поле. Однако при попытке настроить отчет в режиме «1С:Предприятие» обнаруживается неприятная деталь: у поля отсутствует «плюсик», позволяющий раскрыть его реквизиты. Давайте подробно разберем, почему это происходит, чем это опасно для производительности и как правильно решить задачу, сохранив гибкость настроек.

Почему «плюсик» не активен: анализируем механику СКД

Рассмотрим ситуацию с точки зрения платформы. Дерево доступных полей в конструкторе настроек формируется на этапе инициализации схемы компоновки данных. В этот момент система анализирует метаданные, описанные в запросах (Набор данных - запрос). Если поле выбрано непосредственно из таблицы базы данных, СКД четко понимает его тип и структуру реквизитов.

Когда же мы используем вычисляемое поле, значение в котором возвращается функцией общего модуля, для СКД это поле становится «динамическим». Несмотря на то, что вы можете явно указать тип значения в колонке «Тип значения» (например, СправочникСсылка.Должности), система не строит дерево реквизитов для такого поля в визуальном редакторе. Это связано с тем, что вычисление происходит уже на этапе компоновки результата, а не на этапе формирования структуры запроса к базе данных.

Главная опасность: «Запрос в цикле»

Проанализируем, почему разработчики платформы сознательно ограничивают функционал вычисляемых полей. Если бы СКД позволяла легко обращаться к реквизитам поля, полученного через функцию, это неизбежно привело бы к катастрофическому падению производительности. Представьте: у вас в отчете 1000 строк. Для каждой строки вызывается функция (первое обращение), а затем для получения каждого реквизита через «точку» система делает дополнительный запрос к базе данных. В итоге вместо одного эффективного запроса мы получаем тысячи мелких обращений.

Решение 1: Перенос логики в запрос

Самый правильный и эффективный способ — отказаться от вычисляемого поля в пользу получения данных в основном запросе. Если задача стоит в получении «Основного сотрудника» (как в случае с ЗИКГУ/ЗУП), логику поиска этого сотрудника следует интегрировать в текст запроса или использовать временные таблицы.

Разберем алгоритм:

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

Решение 2: Связи наборов данных (Dataset Links)

Если логика получения ссылки слишком сложна для SQL-запроса и требует именно программного кода, воспользуемся механизмом связей. Рассмотрим этот метод по шагам:

1. Создаем Набор данных - запрос (основной).
2. Создаем второй набор данных (например, Набор данных - объект или еще один запрос к справочнику).
3. В основном наборе оставляем идентификатор или ссылку.
4. На вкладке «Связи наборов данных» настраиваем связь по этому идентификатору.

В этом случае все реквизиты связанного справочника станут доступны в настройках отчета как полноценные поля, при этом СКД оптимизирует выборку, минимизируя количество обращений к базе.

Решение 3: Использование программного интерфейса (для ЗУП и ЗИКГУ)

В конфигурациях «Зарплата и управление персоналом» (ЗУП) и «Зарплата и кадры государственного учреждения» (ЗИКГУ) реализован мощный механизм для получения кадровых данных. Вместо написания собственных функций в общих модулях, рекомендуется использовать типовой программный интерфейс.

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

Решение 4: Ручное обращение через точку в выражениях

Если вам не нужно группировать данные по реквизитам, а требуется лишь вывести их в колонки, вы можете прописать путь к реквизиту вручную в выражении другого вычисляемого поля. Выясним, как это сделать:

Допустим, у вас есть вычисляемое поле Должность. Вы можете создать еще одно вычисляемое поле КодДолжности и в колонке «Выражение» написать:

Должность.Код

Важно: «Плюсика» в настройках все равно не будет, но в самом отчете данные появятся. Помните о проблеме производительности — этот метод допустим только для небольших отчетов или редких обращений.

Решение 5: Настройка выражения представления

Иногда нужно просто изменить то, как ссылка отображается в отчете (например, добавить код или артикул рядом с наименованием). Для этого в СКД предусмотрена колонка «Выражение представления». Рассмотрим пример:

Чтобы вывести должность вместе с ее кодом, укажите в выражении представления:

Представление(Должность) + " [" + Должность.Код + "]"

Это позволит пользователю видеть расширенную информацию, не создавая лишних полей в схеме компоновки.

Подводя итог, отметим: отсутствие «плюсика» в вычисляемом поле — это не ошибка, а защитный механизм платформы. Оптимальным решением всегда будет получение данных через соединения в запросе или использование штатных механизмов кадрового учета конфигурации.