При разработке отчетов на базе Системы компоновки данных (СКД) часто возникает задача: сделать так, чтобы при открытии отчета определенный параметр (например, валюта или склад) уже был заполнен значением по умолчанию — для 1С:БП 3.0 есть автоподстановка параметров в отчеты из текущего документа. Это позволяет пользователю сформировать отчет сразу, не тратя время на выбор настроек. Однако стандартные механизмы не всегда ведут себя очевидно, особенно когда речь идет о проверке на "пустое значение" или программном переопределении параметров.
В этой статье мы подробно разберем, почему простые проверки в поле Выражение могут не работать, как правильно использовать логические конструкции внутри схемы компоновки и как программно управлять параметрами, не вызывая лишних вопросов системы о сохранении настроек. Для этой задачи есть платформа для создания управленческой отчетности без программирования.
Проанализируем типичную ошибку: попытку написать условие ВЫБОР КОГДА &Валюта = ЗНАЧЕНИЕ(...) в выражении того же самого параметра &Валюта. Проблема здесь в том, что СКД не может одновременно использовать параметр как источник данных и как результат вычисления. Для решения этой задачи мы применим методику подмены параметра.
Рассмотрим пошагово, как это реализовать:
&ВыбраннаяВалюта. Именно его мы выведем в пользовательские настройки. В поле "Доступные типы" укажем СправочникСсылка.Валюты.&Валюта. Установим для него флаг Ограничение доступности (скроем от пользователя). Именно этот параметр мы будем использовать в тексте нашего запроса.&Валюта напишем конструкцию, которая проверяет выбор пользователя:
ВЫБОР
КОГДА &ВыбраннаяВалюта = ЗНАЧЕНИЕ(Справочник.Валюты.ПустаяСсылка) ИЛИ &ВыбраннаяВалюта ЕСТЬ NULL
ТОГДА Справочники.Валюты.НайтиПоКоду("643")
ИНАЧЕ &ВыбраннаяВалюта
КОНЕЦ
Выясним причину, почему это работает лучше — для реализации подобных алгоритмов поможет автоподстановка значений реквизитов по заданным условиям. Теперь система сначала берет значение, которое ввел (или не ввел) пользователь в &ВыбраннаяВалюта, а затем вычисляет итоговое значение для запроса. Обратите внимание, что код валюты "810" является устаревшим, для современных версий систем лучше использовать "643".
Если логика определения значения по умолчанию слишком сложная для простого выражения (например, нужно проверить права пользователя или данные из констант), мы можем прибегнуть к программному заполнению — для этого есть управление запуском отчетов с предопределенными параметрами. Многие разработчики пытаются делать это в форме отчета в событии ПриОткрытии, но это не самый оптимальный путь.
Проанализируем ситуацию: установка параметров в форме часто приводит к тому, что 1С считает вариант отчета "измененным". Правильнее всего использовать предопределенную процедуру в модуле объекта отчета — ПриКомпоновкеРезультата.
Рассмотрим пример кода:
Процедура ПриКомпоновкеРезультата(ДанныеРасшифровки, СтандартнаяОбработка)
// Получаем нужный параметр из настроек компоновщика
ПараметрВалюта = КомпоновщикНастроек.Настройки.ПараметрыДанных.Элементы.Найти("Валюта");
// Проверяем, заполнено ли значение пользователем
Если ПараметрВалюта <> Неопределено И (НЕ ЗначениеЗаполнено(ПараметрВалюта.Значение)) Тогда
ПараметрВалюта.Значение = Справочники.Валюты.НайтиПоКоду("643");
ПараметрВалюта.Использование = Истина;
КонецЕсли;
КонецПроцедуры
Посмотрим на преимущества этого подхода: во-первых, код выполняется на сервере в контексте формирования отчета. Во-вторых, он срабатывает непосредственно перед тем, как данные будут извлечены, что гарантирует наличие значения.
Разберем важный нюанс работы с типами данных в выражениях СКД. Часто разработчики сталкиваются с тем, что условие &Валюта Есть Null не срабатывает. Выясним причину: в 1С параметры ссылочного типа, если они не выбраны, обычно содержат Пустую Ссылку конкретного типа, а не NULL.
Для надежной проверки в СКД всегда рекомендуется использовать явное сравнение с системным значением:
ЗНАЧЕНИЕ(Справочник.ИмяСправочника.ПустаяСсылка).ЗНАЧЕНИЕ(Перечисление.ИмяПеречисления.ПустоеЗначение) или конкретное значение.Если ваш параметр может принимать несколько типов (составной тип), тогда проверка усложняется. В этом случае полезно в схеме на закладке "Параметры" жестко ограничить тип значения, чтобы система всегда знала, какую "пустышку" ожидать.
Если вы все же решили устанавливать параметры программно через форму (например, в событии ПриОткрытии), вы столкнетесь с тем, что при закрытии отчета система спросит пользователя: "Настройки были изменены. Сохранить вариант?". Это происходит потому, что любое программное изменение КомпоновщикНастроек.Настройки взводит флаг модифицированности.
Чтобы "красиво" обойти этот нюанс, используйте следующий прием в модуле формы:
&НаКлиенте
Процедура ПриОткрытии(Отказ)
// Ваша логика установки параметров...
// Сбрасываем признаки изменения формы и варианта
ЭтаФорма.ПользовательскиеНастройкиМодифицированы = Ложь;
ЭтотОбъект.ВариантМодифицирован = Ложь;
КонецПроцедуры
Проанализируем ситуацию: эти две строки заставляют платформу думать, что форма находится в исходном состоянии, хотя значения параметров уже были подставлены вашим кодом. Это значительно повышает удобство работы пользователя (UX).
Использование НайтиПоКоду в выражениях СКД — это рабочий, но не самый надежный метод. Если код валюты в разных базах будет отличаться, ваш отчет "сломается". Рассмотрим более архитектурно правильные способы:
ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.НазваниеСчета).Константы.ВалютаРегламентированногоУчета.Получить(). Это самый надежный способ получения базовой валюты.МойОбщийМодуль.ПолучитьВалютуПоУмолчанию(). Это позволит сосредоточить логику выбора значения в одном месте.Таким образом, мы рассмотрели несколько способов задания значений параметров по умолчанию. Самым стабильным для простых случаев является метод двух параметров в самой схеме, а для сложных бизнес-задач — использование модуля объекта и события ПриКомпоновкеРезультата — для этого подойдёт набор инструментов для разработчика с консолью СКД.