Отбор в отчете в 1с
Полагаю, нет нужды рассказывать, что такое СКД, компоновщик настроек и вообще весь набор объектов, предназначенных для работы с СКД. Основные направления использования, не считая хитрых действий в коде, это динамические списки и отчёты, причём в обоих случаях «за кадром» остаётся весьма существенный функционал. Мы зачастую даже не задумываемся, какова логика поведения и взаимосвязи всех участников процесса, т.к. обычно решаем достаточно простые задачи или полагаемся на умолчания платформы. Но, где есть умолчания, есть и внутренняя логика, эдакая «медвежья услуга» 1С, преодолеть плоды которой для достижения нужного эффекта иногда трудно и неочевидно, и при этом достаточно лишь правильно воспользоваться инструментарием.
Желающие могут пропустить части 1-4 и сразу перейти к примерам.
Попробую чуть более подробно остановиться на работе отборов СКД для случая их применения в отчётах. Полагаю, поведение в динамических списках, за рядом оговорок, будет близким. Итак, отборы в отчётах, немного теории и потом конкретные примеры.
Используются СП 8.3.6 и выше, разделы ИТС (пункт 10.3.7.5 и др.), книга «Профессиональная разработка в системе 1С-Предприятие 8» (Казань, 2012 г., второй том). В книге Е.Хрусталёвой вообще ничего внятного на эту тему не нашлось.
Часть 1
У компоновщика настроек, как известно, есть коллекции «Настройки», «Фиксированные настройки» (далее «ФН») и «Пользовательские настройки» (далее «ПН»). У отчёта может быть задано несколько вариантов, при этом связи между вариантом, Н, ПН и ФН весьма своеобразны. Также, не будем забывать об источнике доступных настроек, и его «прародителе», которым обычно бывает сама схема, тоже имеющая свои настройки по умолчанию.
* Настройки – настройки, созданные в режиме Конфигуратора и изменяемые в режиме правки варианта отчёта;
* ПользовательскиеНастройки – настройки, которые изменяет пользователь в режиме «1С:Предприятие» сугубо интерфейсно;
* ФиксированныеНастройки – те настройки, которые задаются из встроенного языка, в т.ч. неявно задаются системой. В это свойство попадают значения отбора, которые передаются в форму с помощью ее параметров (структура «Отбор»).
Настройки и ФН схожи по устройству и имеют коллекцию «Отбор» типа «Отбор компоновки данных», доступную для изменения состава в любое время существования отчёта. При этом Настройки доступны для интерфейсного изменения через правку варианта, а ФН вообще никак не доступны. ПН, в свою очередь, это «каша», где равноправными элементами могут быть как сам «Отбор», так и отдельные объекты типа «Элемент отбора компоновки данных» (т.н. вложенный объект). Несмотря на наличие соответствующих методов, изменять состав коллекции элементов ПН программно нельзя, если это ПН самого отчёта, а не сделанные «с нуля» конструктором – 1С сообщит, что «Коллекция пользовательских настроек не может изменять свой состав, так как она связана с настройками компоновки данных.» На ИТС сказано: «Свойство недоступно для записи с помощью встроенного языка.», но, как мы увидим позже, повлиять на ПН можно. «Каша» объектов имеет внутренние связи – она проверяется на непротиворечивость условий при формировании отчёта, и при изменении состава. На ИТС читаем: «Не будут добавляться элементы, которые сами отмечены как пользовательские. Например, в пользовательский отбор не будет помещен элемент отбора, который отмечен как пользовательский. Не будут добавлены элементы, содержащие пользовательские элементы. Например, не будет добавлена группа условий, если в этой группе присутствуют элементы, отмеченные как пользовательские. Для вложенных элементов свойство РежимОтображения не анализируется. Они добавляются или не добавляются вместе с родительскими элементами.» Таким образом, негласно действует «старшинство» объектов. При этом можно получить эффект, когда интерфейс позволит указать противоречивые отборы для варианта и его ПН, а также внутри ПН.
Казалось бы, «старшим» является вариант. Но нажатие на "Ещё"/"Изменить вариант" и подтверждение изменений в открывшейся форме вызывает обработчик события формы ПриОбновленииСоставаПользовательскихНастроекНаСервере, при этом отбор появляется в панели "Основные" на форме, вызываемой из "Настройки. ", и появляется на форме отчёта, но НЕ показывается на закладке "Отбор"; причём либо он появляется сразу и на основной форме отчёта, и на форме по "Настройки. " (если есть флаг "Включать в пользовательские настройки"), либо ни там, ни там. Но в любом случае на закладке "Отбор" формы "Настройки. " его НЕ будет. Разница между закладкой "Основные" формой "Настройки. " и основной формой отчёта определяется полем "Режим редактирования" (обычный - только в "Настройках", быстрый - ещё и на самой форме отчёта), но это, думаю, все знают. Кстати, значения «Отбора» и «Быстрых» никак не синхронизированы и могут противоречить друг другу, а вот «Быстрый» на форме отчёта и на форме настроек жёстко синхронны. Так вот, при правке варианта он сам становится изменённым (но его ID и имя не меняются), а вот ПН остаются НЕ модифицированными (т.е. даже если речь о них, т.е. о флаге включения того или иного элемента в ПН).
Нажатие на "Выбрать вариант. " и подтверждение изменений в открывшейся форме вызывает в следующем порядке события:
При этом ни вариант, ни ПН ничем и никак не изменяются. Отсюда ясно, что вариант и настройки если и связаны, то отнюдь не напрямую.
Нажатие на "Настройки. " и подтверждение изменений в открывшейся форме вызывает только событие ПриОбновленииСоставаПользовательскихНастроекНаСервере (при этом ПН становятся изменены, но представления и ключа (если их не было) не получают; если включён «Быстрый» для элементов объекта «Отбор» ПН, то кроме "Отбор", появляются и собственно его элементы как поля, т.е. ведёт себя аналогично вложенным элементам. Эти сделанные настройки сохраняются при закрытии и восстанавливаются при следующем входе в форму. Вариант оно никак трогает и не меняет.
Нажатие на "Ещё"/"Установить стандартные настройки" в форме настроек (а также и пункт «Стандартные настройки» в правке варианта) вызывает только событие ПриОбновленииСоставаПользовательскихНастроекНаСервере. При этом вариант становится изменённым, а вот ПН меняются. Если перед этим вариант был изменён, он остаётся изменённым (ни сброса флага изменённости, ни сброса реально сделанных настроек не происходит).
Нажатие на «Свойства элемента пользовательских настроек" в дереве структуры на форме правки варианта добавляет объект "Отбор", и он получается пуст и никак не синхронизируется с уже имеющимся отбором варианта и имеющимися вложенным элементам отбора. Вариант при этом никак не меняется.
Отсюда рекомендация: если надо в режиме «Конфигуратор» задать некие отборы, чтобы не возиться с кодом и чтобы при этом их не было в варианте, но были бы в интерфейсе отчёта – следует манипулировать не элементами отбора варианта, меняя их свойства, а самим отбором, кнопками «Свойства элемента…» и «Пользовательские настройки».
Добавление чего-либо, появившегося в Настройках, в состав ПН, требует действий в коде или интерфейсе, а вот удаление и очистка Настроек сказываются на ПН сразу и безо всяких обновлений, например:
Перед закрытием формы отчёта система спрашивает, только если были изменения варианта. Если были изменения ПН, они сохранятся автоматически безо всяких вопросов, и так же автоматически попытаются примениться в следующем сеансе работы с отчётом.
Примечания:
При добавлении отбора на форме "Изменить вариант" он делается сразу с установленным флагом "Включать в ПН", но, повторюсь, с точки зрения встроенного языка ПН остаются неизменными.
Установка изменённости варианта и установка изменённости ПН не связаны напрямую, это два разных направления изменений.
У ПН, помимо прочего, есть «Дополнительные настройки». Мне никак не удалось понять, чем и в какой момент они заполняются. Хотя в отчёте и есть настройки, "отмеченные в отборе и условном оформлении" как пользовательские (согласно СП), но дополнительные настройки во всех случаях оказывались пусты. На ИТС об этом ничего.
Несмотря на утверждение в СП, ПН прекрасно сериализуются в xml.
Если включены к использованию и независимые элементы отбора, и сам отбор, то отчёт компонуется верно, но при показе задваивает информацию об установленном отборе в итоговом макете.
Генерируемая по умолчанию форма правки варианта отчёта содержит множество интересных вещей, но нигде не работает с ФН и ПН, да и с основными настройками работает больше на чтение (разве что очищает выбор, порядок, усл.оформление).
Часть 2
Работа с Настройками и ФН через их коллекцию почти всегда допустима, но важно помнить, что меняется сущность «третьего уровня». На первом уровне всегда находятся настройки самой СКД по умолчанию, они же фигурируют неявно в источнике доступных настроек; на втором уровне – настройки используемого варианта. Но тут логика позволяет либо «затереть» нижележащие указания, либо их проигнорировать. А вот работа с ПН вольностей уже не предусматривает, и тонкие манипуляции надо делать с помощью специальных методов, а иногда и временных вспомогательных объектов-посредников, например:
У компоновщика настроек имеется метод ЗагрузитьПользовательскиеНастройки(), который загружает значения пользовательских настроек, переданные в качестве параметра метода. Метод ПолучитьНастройки() позволяет получить копию текущих настроек (с учетом пользовательских настроек). Метод ЗагрузитьНастройки() загружает переданные настройки в компоновщик настроек (пользовательские настройки также перезаполняются на основании переданных данных, с учётом наличия ключей, см. пример ниже).
Применение пользовательских настроек к основным настройкам выполняется в методе ПолучитьНастройки() компоновщика настроек. При этом выполняются следующие действия:
* Для типов ЭлементОтбораКомпоновкиДанных содержимое элементов копируется в соответствующие пользовательские элементы настроек.
* Для типов ОтборКомпоновкиДанных элементы, находящиеся в основных настройках и отмеченные как Недоступный, остаются без изменения. Элементы из ПН переносятся в основные. Они добавляются в конец коллекции для Отбора.
* Для типов ГруппаЭлементовОтбораКомпоновкиДанных устанавливается свойство Использование в соответствующем элементе основных настроек (на основании признака использования элемента ПН).
Часть 3
При формировании окончательной настройки, если цитировать ИТС, различные варианты настроек комбинируются следующим образом:
* Если какой-либо вид настроек целиком отмечен как пользовательский, то в результирующие настройки попадают ПН. При этом, если какие-либо элементы настроек отмечены как недоступные, то эти настройки будут помещены в результирующие настройки из свойства КомпоновщикНастроек.Настройки.
* Если какой-либо вид настроек отмечен как пользовательский не целиком, а поэлементно, то элементы, отмеченные как пользовательские, попадут в результирующие настройки из свойства КомпоновщикНастроек.ПользовательскиеНастройки, а элементы, отмеченные как недоступные, будут взяты в результирующие настройки из свойства КомпоновщикНастроек.Настройки.
* Фиксированные настройки добавляются в результирующие настройки «как есть». При этом недопустима ситуация, когда в ФН и ПН есть одноименные настройки, например отбор с одинаковым левым значением в условии. Замечу, что даже полнейшее совпадение всех свойств этих условий запрещено. Честно говоря, несколько нелогично.
Замечу, что, если какой-либо фрагмент настроек подпадает под действие функциональной опции и должен быть ограничен, система работает «втихую» - убирает этот фрагмент отовсюду, ничего не сообщает, а при программных манипуляциях, касающихся такого фрагмента, отрабатывает «вхолостую» - ошибок не выдаёт, но и эффекта от кода никакого. Впрочем, возможно, разные релизы ведут себя по-разному.
Часть 4.
Расширение формы отчёта предоставляет нам параметры «ФН» и «ПН», однако нигде не рекомендуется заполнять их напрямую, передавая в форму. Как показали эксперименты, без дополнительных танцев с бубном наполнение этих параметров игнорируется – оно затирается при инициализации компоновщика в процессе открытия и при получении ранее сохранённых ПН. Рекомендуется работать с ключами ПН, по которым получать их из хранилища настроек и уже тогда раскрывать и использовать, и делается это автоматически на стороне формы отчёта, а не вызывающей формы.
Параметр «ИсточникДоступныхНастроек» автоматически транслируется в сведения компоновщика уже при создании формы на сервере и переопределяться не может. Вернее, может, но эффект это даст только после полного переопределения всей цепочки связанных объектов. При этом ПолучитьИсточникДоступныхНастроек() вплоть до конца отработки всех событий открытия формы будет возвращать Неопределено.
Замечу, что параметры формы, по сути не являющиеся ключевыми, «растягивают» своё действие на несколько событий, если установлен флаг формирования при открытии. Так, в событии ОбработкаПроверкиЗаполненияНаСервере, вызванном при открытии и формировании, параметр «Отбор» будет доступен, а при нём же, но вызванном просто нажатием пользователя на кнопку «Сформировать» - уже нет. Связано это с тем, что все эти события отрабатывают за одно «посещение» сервера, если формирование при открытии включено, и только в самом их конце управление передаётся на клиент и вызывается ПриОткрытии. При этом неключевые параметры, естественно, теряются.
Общий порядок выполнения событий при открытии формы с флагом формирования отчёта при открытии (несколько больше, чем описано в «Проф.разработке»):
При этом ни вариант, ни ПН не являются изменёнными, если не предпринимались специальные усилия.
Часть 5.
Теперь остановимся более подробно на задаче открытия формы отчёта с его построением и предварительно указанным отбором. Краткие сведения об этом есть на ИТС и в методических рекомендациях, но там освещён только сам принцип и не раскрыты тонкости. Итак, для контекстного вызова отчёта необходимо передать его форме параметр «СформироватьПриОткрытии», равный Истина; и параметр «Отбор», содержащий структуру. Ключи структуры – это имена полей СКД или параметров СКД, а значения и есть их значения. Цитируя СП, если есть параметр СКД с именем, соответствующим имени ключа структуры, то значение будет установлено ему. Если параметра нет, но есть поле, то будет добавлен отбор на это поле. При этом, если есть одноимённые параметр и поле, то система просто тихо это проигнорирует и не установит ничего.
В «Проф.разработке» приведён пример изменения (т.е. перехвата и перенастройки) ПН «на лету» в событии ПередЗагрузкойПользовательскихНастроекНаСервере, куда передаётся аргумент, содержащий текущие ПН. На самом деле это не всегда так – например, возможны случаи, когда ошибка сохранения ПН в предыдущем сеансе, или противоречия между Настройками, ФН и ПН приведут к тому, что аргумент «Настройки» будет пуст. И что самое интересное, полноценно перенастроить его в этом событии не удастся, это можно сделать только «в конце» последовательности событий, а именно, в событии ОбработкаПроверкиЗаполненияНаСервере.
Посмотрим, что мы имеем перед загрузкой ПН на сервере.
Для простого случая, когда в СКД ничего не предзадано и никакие элементы не включены в ПН, ситуация такова: Настройки – пусты; ФН – содержат правильный отбор; ПН содержат пустой Отбор. Формирование работает правильно, но с точки зрения пользователя интерфейс противоречит внутренностям и обескураживает – отбор работает, но не виден. Аналогично, если в настройках структуры варианта включить Отбор в ПН, отчёт также строится с учётом отбора, но пользователь также не видит никакие отборы.
Зададим в настройках СКД в Конфигураторе предотборы (равные пустым значениям) и включим их в ПН. По идее, ФН должны заполнить Настройки, а те – ПН, но на самом деле имеем: в Настройках – Отбор с нужным элементом, но пустым правым значением, ФН – содержат правильный отбор, а ПН – всё равно не содержат ничего. Вдобавок, в этом случае и отчёт не построится, т.к. правое значение отбора пусто, несмотря на переданное в параметре Отбор значение.
Попытка поработать с элементами ПН также не даёт результата. Для элемента ПН можно изменить разве что флаг «Использование» и участие в «Быстрых». Значение отбора на интерфейсе будет пустым, никаких ошибок система не выдаст. Аналогично, попытка поработать с Отбором ПН также отработает, в отладчике правое значение будет видно как верно заполненное, но на интерфейсе вы не увидите ничего. А менять состав ПН, напомню, нельзя. Таким образом, требуются дополнительные ухищрения. Например:
Вызывать это наиболее правильно так:
Тогда, контекстный вызов, например, из формы справочника, будет выглядеть так:
Часть 6.
При необходимости менять настройки отчёта в процессе работы с ним, в т.ч. и при запуске, и после открытия, наиболее правильным способом представляется изменение «от начала», т.е. от настроек СКД. Изменение схемы СКД выполняется только с объектом Отчёт (или ВнешнийОтчёт), а не с данными формы, и само по себе ничего не меняет - в Настройках и в ПН остаётся то же, что и было, а ФН вообще могут оставаться пусты. Поэтому, в зависимости от наших задач:
изменяется только вариант, и ничего более;
После выполнения приёма, приведённого в п.2 (с использованием «посредника» и метода ЗагрузитьПользовательскиеНастройки()
срабатывает, только если сбросить текущие ПН средствами интерфейса. Сами по себе они, при изменении варианта, не изменятся. При этом меняется Отбор, но не добавляется новый ЭлементОтбора.
платформа просто тихо падает. Проверено на нескольких разных релизах. А вызов с режимом отображения настроек только для быстрых не имеет смысла – мы же не повлияли на их состав, поэтому ничего всё равно не изменится.
А поскольку нам всё-таки нужно полноценно изменить не только внутренние отборы, но и отображение на форме отчёта и в связанных формах, то либо приходится менять только Отбор, либо действовать следующим образом:
Собственно, изучать эту механику можно ещё долго. Эта публикация выросла из изучения способов решения одной конкретной проблемы, и поэтому весьма однобокая; но подоздреваю, что о внутренней логике настроек, особенно пользовательских, вообще можно написать отдельную книгу не тоньше, чем хрусталёвская. У меня на это, к сожалению, сил и времени нет. Кому пригодятся конкретные наработки - уже хорошо.
Кое-что выяснено экспериментально и потому спорно. Знающие больше - приглашаются критиковать и комментировать.
Войдите как ученик, чтобы получить доступ к материалам школы
Система компоновки данных 1С 8.3 для начинающих: делаем отбор и сортировку на уровне СКД
Автор уроков и преподаватель школы: Владимир Милькин
Ставим цель
- Создать новый отчёт "Урок5.erf".
- Вывести в этом отчёте города (включая название города, мэра и численность).
- Упорядочить города в списке по численности (по возрастанию)
- Прямо на форме отчёта дать пользователю возможность делать отбор городов по минимальной численности.
Создаём новый отчёт в конфигураторе
Открываем базу "Гастроном" в конфигураторе.
Из главного меню конфигуратора выбираем пункт "Файл"->"Новый. ":
Вид документа: "Внешний отчет":
В качестве имени пишем "Урок5" и нажимаем кнопку "Открыть схему компоновки данных":
Соглашаемся с именем схемы компоновки данных по умолчанию:
В открывшейся схеме компоновки данных добавляем набор данных - запрос:
Составляем запрос
Запускаем конструктор запроса:
Из таблицы справочника "Города" выбираем поля: "Наименование", "Мэр" и "Численность":
Получился такой запрос:
Выводим отчёт в виде списка
Переходим на закладку "Настройки" и нажимаем волшебную палочку, чтобы вызывать конструктор настроек:
Тип отчёта выбираем "Список":
В отчёте будут отображаться следующие поля:
Сохраняем отчет и тут же проверяем в режиме пользователя:
Сортируем города по численности
Теперь давайте упорядочим записи отчёта по возрастанию численности.
Для этого переходим на вкладку "Настройки", выбираем пункт "Отчет", ниже выбираем вкладку "Сортировка" и перетаскиваем поле численность из первой колонки во вторую.
Направление сортировки указываем "По возрастанию":
Сохраняем отчёт и проверяем в режиме пользователя:
Делаем отбор городов по численности
Теперь давайте сделаем так, чтобы в отчёте выводились только города с численностью от 1 миллиона человек (включительно). Такая возможность называется отбор.
Переходим на вкладку "Настройки", выбираем пункт "Отчет", далее переходим на вкладку "Отбор" и перетаскиваем поле "Численность" из левой колонки в правую.
В качестве вида сравнения указываем "Больше или равно", а в качестве правого значения - 1000000:
Сохраняем отчет и проверяем в режиме пользователя:
Видим, что остались города с численностью больше миллиона и этот факт (отбора) явно отражён в заголовке отчета.
Выносим параметр отбора на форму отчета
Осталось сделать так, чтобы пользователь мог сам настраивать пороговое значение отбора. Другими словами, чтобы вместо миллиона он мог поставить свою цифру.
Заходим на вкладку "Настройки", выделяем пункт "Отчет", внизу выбираем вкладку "Отбор", выделяем элемент отбора "Численность" и нажимаем справа внизу на зелёный плюсик:
В открывшемся окне ставим галку "Включать в пользовательские настройки":
Вновь сохраняем отчет и запускаем в режиме пользователя.
Видим, что появилось поле "Численность" меняя условие и значение которого мы управляем отбором городов в отчёте:
Войдите на сайт как ученик
Для учеников
Прибегайте к изучению эталонного варианта только после самостоятельного выполнения всех шагов.
На вопросы учеников — отвечаю по почте, но прежде загляните в ЧАВО (ссылка) .
Нередко программистам для написания обработок приходилось использовать запросы для получения данных и последующей их обработке. Данные в свою очередь, получались из запроса. Ну а запрос без отбора или фильтра это редкость. Поговорим об отборах в таких запросах, на примере запроса:
Для того, чтобы организовать отбор по контрагенту для пользователя в обычной форме, программисту приходилось размещать три элемента на форме, что выглядело примерно так:
Сколько трудов стоит описать программисту разные виды сравнения (равно, не равно, в списке, в группе…) и исходя из этих видов сравнения дорабатывать свой конечный запрос получения данных.
Рассмотрим, как это можно сделать при помощи СКД. Создадим в нашей обработке Макет с типом Схема компоновки данных и заполним его нашим запросом:
На вкладке Настройки добавим новую группировку без детализации и, в нашем примере, поле Контрагент, так как в итоге мы получим все в таблицу значений:
И на вкладке Отбор добавим в отбор Контрагента:
Далее в самой обработке создадим реквизит Компоновщик типа КомпоновщикНастроекКомпоновкиДанных:
Теперь займемся оформлением формы. Выведем на форму самой обработки Отбор, с которым будет работать пользователь. На форму выведем элемент типа Табличное поле и дадим ему имя Отбор с типом данных Компоновщик.Настройки.Отбор:
Далее ниже выведем эелемент Табличное поле с именем Результат и типом ТаблицаЗначений и кнопку Выполнить, по которой и будем выводить таблицу с контрагентами:
Теперь создадим обработчики событий формы ПриОткрытии и обработчик нажатия кнопки Выполнить, код представлен ниже:
Обработка готова, запустив ее, можно при запуске сразу увидеть в нашем Отборе появившегося Контрагента, у которого можно выбирать любой тип сравнения, а также и добавлять дополнительные строки отбора по реквизитам справочника Контрагенты:
На этом все, надеюсь, данная статья поможет Вам улучшить гибкость отборов в Ваших обработках.
Редко какой отчет в 1С не использует отборы, разве что печатные формы и какие-то специальные отчеты. В большинстве отчетов в 1С требуется возможность выборочного анализа. Поэтому в этой статье мы поговорим про настройку отборов в отчетах, построенных с помощью 1С СКД.
После того как вы добавили наборы, определили ресурсы, задали структуру отчета с помощью группировок , можно приступать к настройке фильтров. В СКД это делается на закладке «Отбор», которая доступна или для всего отчета или для определенной группировки.
Новый элемент в список отбора можно добавить несколькими способами – двойной клик по доступному полю, перетаскивание, клавиша в меню:
При этом только через клавишу в меню можно добавить группу в отбор, которая объединяет элементы внутри этой группы по заданному условию (И, ИЛИ).
По умолчанию если элементы отбора не включены ни в какую группу и объединяются с помощью оператора «И».
Вид сравнения в элементе отбора зависит от типа поля (левого значения):
Операции доступные для числа:
Операции доступные для строки:
Для строки добавлены операции – «содержит», «начинается с», «соответствует шаблону» и те же операции с оператором «Не» (Не содержит и т.д.).
Операции доступные для ссылки:
Далее разберем типовые ситуации при использовании отбора
Самый простой вариант использование отбора – добавить фиксированный отбор, который будет действовать всегда (если конечно пользователь не изменит его в варианте отчета):
Обычно такие отборы имеет смысл переносить в текст запроса. Особенно в том случае, если пользователь не должен его менять вообще ни при каком условии.
Иногда в отчете на 1С СКД возникает необходимость исключить в отчете значения некоторых группировок (колонок или строк). Причем сделать это в запросе не представляется возможным, потому что исключать такие строки возможно только после компоновки.
В этом случае используется возможность СКД накладывать отборы на заданную группировку. Рассмотрим, например, такой отчет:
Допустим нам нужно исключить из отчета все строки, в которых итоговое количество по номенклатуре меньше 15. В запросе мы такое условие применить не можем. Установим для этого отбора для группировки «Номенклатура»:
Получим такой отчет:
Отборы на группировках часто используются в отчетах вида «Ведомость по остаткам»:
При использовании группировки по периоду (регистратору) в таких отчетах появляются строки, отвечающие за начальный остаток при использовании даты начала периода отличной от самой ранней. Чтобы убрать такие строки, можно использовать отбор на группировке по регистратору:
Чтобы убрать отбор, выделенный на рисунке на закладке «Другие настройки» для этой же группировки отключим вывод отбора:
Обычно мы редко используем фиксированные отборы. Чаще нам нужны отборы, которые может изменять пользователь. Можно, чтобы пользователь изменял отборы через функционал 1С СКД «Изменить вариант», но это не совсем верный путь – вариант отчета это скорее постоянный «скелет», который настраивается один раз и потом используется многократно. Отборы же это что-то часто изменяемое, поэтому правильнее редактировать их через механизм пользовательских настроек.
Итак, вернемся к нашему отчету. Допустим нам необходимо добавить в отчет отбор по группе номенклатуры (или по элементу) и чтобы этот отбор был доступен для изменения пользователем.
Добавим для этого отбор на уровне отчета. Вид сравнения по умолчанию сделаем «В группе», отключим по умолчанию использование отбора и в диалоге редактирования пользовательских настроек включим наш отбор в пользовательские настройки.
Перейдем теперь в режим предприятия.
Наш отбор доступен для редактирования на форме. За доступность прямо в форме отчета отвечает «Режим редактирования». Значение «Быстрый доступ» означает, что отбор доступен прямо на форме отчета. Если значение равно «Обычный», отбор доступен через кнопку «Настройки». Как видно на рисунке пользователь может выбирать вариант сравнения, управлять действием (включен / отключен) отбора.
Если вам необходимо установить фиксированный отбор (вид сравнения и правое значение константы), но пользователь должен управлять включением / отключением отбора, тогда вам необходимо заполнить представление отбора в пользовательской настройке:
В этом случае в настройки добавляется только флаг использования отбора, которым может управлять пользователь:
Если вам в отборе нужно изменить представления поля, по которому делается отбор, то для этого есть еще одно представление:
Получается вот так:
Мы можем вывести все отборы для редактирования пользователем. Для этого на уровне отчета вызовем диалог редактирования пользовательских настроек:
То же самое можно сделать на уровне любой группировки, если нужно, чтобы была возможность редактирования отборов для заданной группировки. В режиме предприятия это выглядит следующим образом:
Как известно, в 1С СКД используется не только в отчетах, но и в формах, содержащих динамические списки. У динамического списка есть несколько свойств, которые относятся к СКД. Среди этих свойств имеется свойство «Отбор» с типом «ОтборКомпоновкиДанных». Чтобы установить отбор в динамическом списке есть два способа. Первый способ – передать отборы через параметр формы с одноименным названием – «Отбор». Этот параметр является структурой, в которой ключ ссылается на поле, для которого устанавливается отбор. Значение же содержит данные, с которыми производится сравнение. Можно также передать в качестве правого значения – массив, фиксированный массив, список значений. В этом случае вид сравнения равняется «ВСписке», для одиночного элемента вид сравнения устанавливается как «Равно». Этот способ ограничен в возможностях – с его помощью нельзя накладывать сложные условия с операторами «И» и «ИЛИ», нельзя использовать виды сравнения кроме двух указанных.
Отбор, установленный таким образом, передается в фиксированные настройки компоновщика настроек, связанного с динамическим списком. Он не виден пользователю и недоступен для изменения.
Второй способ – непосредственное редактирование отбора в динамическом списке или в компоновщике. Обычно в типовых конфигурация для этого есть ряд методов и функций для установки таких отборов.
Например, вызов основного метода для установки отбора выглядит так:
ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбора(Список.Отбор, «Ссылка», Параметры.ДобавитьДля, ВидСравненияКомпоновкиДанных.НеРавно);
Данная функция производит поиск существующего элемента отбора, изменяет его если нашла, а если не нашла, то добавляет с помощью такой процедуры:
В форме содержащей динамический список также как в отчете на СКД, возможно настроить пользовательский отбор. Как это можно сделать показано на рисунке:
Также у элемента формы, с которым связан список нужно установить группу пользовательских настроек, в которой будут отображаться настройки для пользователя:
В данной статье мы рассмотрим практически все возможности и множество нюансов, которые относятся к параметрам в Системе Компоновки Данных 1С (в сокращении — СКД). Параметры в запросе СКД, фигурные скобочки в запросе СКД — оно же Расширение языка запросов для СКД, особенности настройки страницы “Параметры” СКД, вывод параметров на форму, программная установка параметров, мягкие и жесткие параметры.
Параметры могут использоваться практически в любом месте запроса и выполнять самые различные функции.
Параметры обозначаются знаком & после которого следует имя параметра.
Параметр может быть полем запроса, частью произвольного выражения поля запроса, условием для виртуальной таблицы, частью выражения в отборе запроса и так далее:
При построении запроса конструктором на вкладке “Условия” если не стоит галочка “Произвольное”, то конструктор считает что в правом значении параметр и он записывается без символа &.
Таким образом этот блок настраивается в конструкторе.
Если значение параметра не задано, то построение СКД будет невозможно и будет выдана ошибка, поэтому такие параметры называют “обязательными” или “жесткими”.
Выбрать.
Этот блок располагается в запросе типа выборка данных пакета запросов СКД в первом запросе объединения между перечнем полей и “ИЗ” и заключается в фигурные скобки.
В этом блоке мы перечисляем поля, которые пользователь может выбирать для вывода, группировки и упорядочивания. Конструкция «.*» в параметре “Марка.*” позволяет выбирать для вывода, группировки и упорядочивания дочерние поля значения, например, Марка.Код. Слово “КАК” позволяет задать псевдоним, например, “Ссылка КАК Машина”. Поля в этом блоке попадают в перечень полей набора, даже если отключено автозаполнение. Если автозаполнение включено, то упомянутые поля попадают в соответствии с тем, как они настроены расширением кода, то есть если ссылочное поле без конструкции “.*” дочерние поля доступны не будут, если указан псевдоним — именно он попадет в перечень полей набора.
Таким образом этот блок настраивается в конструкторе.
При автоматическом заполнении полей набора данных, для не включенных в блок расширения “ВЫБРАТЬ”, добавляются все поля списка выборки и их дочерние поля. Они становятся доступными для выбора, упорядочивания, группировки, отбора. Также добавляются поля, которые упомянуты в параметре “Условия” виртуальных таблиц как доступные для отбора.
Отбор, установленный в пользовательских настройках, будет действовать не только на основной запрос, но и на все запросы в пакете. Но это не всегда соответствует логике отчета, к примеру, если помимо отобранной номенклатуры и сумм по ней нужно выводить общую сумму продаж для сравнения. В таких случаях нам нужны специфические отборы в каждом запросе пакета.
Блок расширения “ГДЕ” может быть расположен после или вместо обычного блока “ГДЕ” в любом запросе, подзапросе, запросах объединения и заключается в фигурные скобки. Для присвоения отбору псевдонима используется конструкция “КАК”. Псевдоним нужно использовать чтобы отбор производился конструкцией расширения языка запросов, но не происходил автоматически по наименованию поля.
Если автозаполнение полей набора отключено, поля из этого блока попадают в перечень полей набора доступными только для отбора, использование дочерних полей зависит от наличия конструкции “.*”.
Если автозаполнение включено, и это поле включено в блок расширения “ВЫБРАТЬ” тогда настройки обоих блоков объединяются. Если не включено в “ВЫБРАТЬ” то поля попадают доступными для вывода, группировки, отбора и упорядочивания.
В случае если нужно дополнительно установить какое то ограничение полю, то можно вручную установить галочку в соответствующее поле перечня полей набора данных СКД.
Параметры в блоке «ГДЕ» не обязательны для заполнения, поэтому эти параметры называют “необязательными” или “мягкими”.
Также в блоке “ГДЕ” вместо параметра может быть произвольное выражение с использованием конструкции ВЫБОР или параметров со страницы “Параметры” СКД. Правда в последнем случае вид сравнения необходимо указывать конкретно.
Нужно с осторожностью использовать вид сравнения МЕЖДУ поскольку:
Если параметры НачалоПериода и КонецПериода не будут заданы, то система получит документы за весь период.
Если параметры НачалоПериода и КонецПериода будут заданы, то система получит документы за указанный период.
Если какой-то один из параметров не будет задан, то система выдаст ошибку.
Один из вариантов решения это разбить МЕЖДУ на два условия чтобы система не выдавала ошибку в случае одного незаполненного параметра.
Это же замечание относится к любым выражением с использованием нескольких параметров.
Параметры виртуальных таблиц.
В параметрах виртуальных таблиц в отличие от предыдущих блоков, каждый параметр заключается в фигурные скобки. В полях относящихся к периоду название параметра ставится с &. Пример &ДатаНачала. В поле “Условие” параметры оформляются аналогично блоку “ГДЕ”.
Поведение параметров из поля “Условие” при снятии или установке галочки “Автозаполнение” также аналогично блоку «ГДЕ».
Параметры из полей периода попадают на страницу “Параметры” СКД. Если автозаполнение включено и в поле периода параметр не вписан, параметры с именем поля периода будут автоматически созданы на странице “Параметры” СКД.
Таким образом, эти параметры заполняются в конструкторе запроса. Для открытия формы “Параметры виртуальной таблицы” нужно выбрать виртуальную таблицу в списке таблиц и нажать выделенную синим кнопку. Также тут у таблиц есть булевый реквизит “Обязательная” и числовой реквизит “Номер группы”. Если признак обязательности таблицы не установлен, то она будет добавляться в результирующий запрос только в случае, когда хотя бы одно поле из нее задействовано в компоновке. Номер группы заполняется для необязательных таблиц и обозначает группу таблиц, которые будут добавлены в результирующий запрос только, когда из этой группы таблиц задействовано хотя бы одно поле.
В параметрах виртуальных таблиц возможно совместное использование “жестких” параметров запросов и “мягких” параметров компоновки данных.
В этом примере если в настройках установлено значение параметра &НачалоПериода, то будет использоваться его значение. В противном случае в качестве значения параметра виртуальной таблицы будет использоваться значение “жесткого” параметра “&Начало”.
Если автозаполнение включено и в поля периода не вписаны “мягкие” параметры компоновки данных то параметры с именем поля периода будут автоматически созданы на странице “Параметры” СКД и текст запроса:
будет соответствовать следующему:
В этом случае “мягкие” параметры также будут иметь приоритет над “жесткими”.
Обзорный вид страницы.
На эту страницу автоматически добавляются все параметры из запроса. Можно добавлять свой параметр в для использования его в вычисляемых полях например.
Строка параметра имеет следующие реквизиты:
Имя — это имя параметра, с помощью которого к его значению можно обращаться в тексте запроса, в вычисляемых полях и других местах где доступны выражения.
Заголовок — название, выводимое пользователю.
Тип — определяет тип параметра. Иногда при выборе дат периода, пользователю не нужно указывать время. Тогда нажав на “…” можно указать состав даты — Дата.
Таким же образом можно указать формат числа для численного параметра и длину строки для строкового.
А для того чтобы введенные значения интерпретировались в отчете как начало и конец дня следует в запросе использовать функции НачалоПериода() и КонецПериода() .
Доступные значения — определяет перечень доступных значений. Представляет собой список значений со стандартными полями — значение и представление, где значение типа параметра. Для ссылочного типа доступны для выбора только предопределенные данные.
Доступен список значений — определяет доступность параметру принимать значение “список значения”.
Значение — предустановленное значение параметра. Типа параметра. Для ссылочного типа доступны для выбора только предопределенные данные.
Выражение — выражение, значение которого примет параметр. Что примечательно здесь могут использоваться как функции встроенного языка запросов, так и функции встроенного языка программирования и даже функции из общих модулей. К примеру, параметру ТекДата присваивается значение функции встроенного языка программирования ТекущаяДата().
Также в примере к реквизиту “Тип” можно было в выражениях использовать функции встроенного языка запросов, особенность применения этих функций в данном месте такова, что строковые параметры функций надо брать в кавычки.
и в запросе можно было бы писать проще поскольку в параметрах уже будет содержаться начало и конец периода:
Иногда, для повышения удобства пользователю для выбора периода лучше дать не два поля с типом Дата, а одно поле с типом Стандартный Период. Тогда, к примеру, создаем три параметра: “Период” с типом СтандартныйПериод, “ПериодНачало” и “ПериодОкончание” с типом Дата. Первый параметр без ограничения доступности. Вторые с ним. В выражение “ПериодНачало” пишем “&Период.ДатаНачала”, в “ПериодОкончания” — “&Период.ДатаОкончания”.
Даты начала и конца стандартного периода также содержат и время. ДатаНачала имеет время 00:00:00, а ДатаОкончания 23:59:59. Получится что пользователь выберет стандартный период в “Период” а разработчик будет использовать корректные “ПериодНачало” и “ПериодОкончание”.
Параметр функциональной опции — используется в механизме функциональных опций.
Включать в доступные поля — включает параметр в доступные поля для выбора в настройках.
Ограничение доступности — ограничивает возможность изменения значения параметра пользователем.
Запрещать незаполненные значения — если установлено и значение параметра не заполнено — отчет не сформируется и выдаст ошибку.
Использование — устанавливает использование параметра. Если установлено Авто и параметр используется в запросе или выражениях, а пользователь перед формированием не установит галочку около параметра — отчет при формировании выдаст ошибку. Пользователь может установить эту галочку непосредственно, или она установится автоматически при изменении значения параметра. Если установлено Всегда, то этой проверки на то, что пользователь заполнил этот параметр — не будет.
Параметры редактирования — содержит настройки редактирования как у поля формы.
В настройках варианта мы можем установить галочку “Отображать недоступные параметры”, это можно использовать если для разных вариантов мы хотим использовать разный набор параметров.
У параметров в табличной части мы можем установить значение по умолчанию для варианта, включить использование по умолчанию установив галочку слева. Нажав на кнопку, расположенную справа внизу, мы открываем окно пользовательских настроек параметра.
В пользовательских настройках мы можем включить параметр в пользовательские настройки. Установим режим редактирования обычный. Тогда он будет доступен в форме, вызываемой кнопкой “Настройки…”.
Если Режим редактирования установить Быстрый доступ, то параметр появится на форме.
Если у параметра “Период” представление заполнить строкой “ПеРиОд”, то вместо название будет показано содержания поля представление.
Если у отчета СКД нет формы, то платформа создаст автоматическую, на которой будут табличный документ результата, кнопки управления и быстрые пользовательские настройки.
Можно создать свою форму для отчета и вывести на нее табличное поле со всеми пользовательскими настройками. Вот так:
Для этого в созданной форме в конфигураторе вытаскиваем на форму Пользовательские настройки из Компоновщика отчета.
В некоторых случаях параметр не прост, и для его расчета нужен некий алгоритм с циклом или ветвлениями. К примеру если отчет формируем в понедельник то в отчете сравниваются продажи по дням позапрошлой и прошлой недели, а в остальные дни недели сравниваются продажи по дням прошлой и текущей недели. Получается у нас от значения дня недели текущего дня зависит сразу четыре параметра: &НачалоПрошлойНедели, &КонецПрошлойНедели, &НачалоТекущейНедели и &КонецТекущейНедели. А еще нам надо дать возможность пользователю формировать отчет как будто он сформирован вчера или неделю назад. В таком случае мы создаем реквизит формы ТекДата типа Дата. Выводим его на форму. В событии ПриИзменении() пишем.
Таким образом можно программно менять параметры из формы.
Параметры это ключевой инструмент для управления отчетом. Использование параметров дает возможность решить множество прикладных задач, таких как калькуляция на основе информации в базе и значений введенных интерактивно для конкретной калькуляции и многих других. В данной статье рассмотрены практически все относящиеся к параметрам механизмы и особенности. Рамках статьи не рассмотрен блок “Характеристики” Расширения языка запросов для СКД поскольку он не касается параметров. Не рассмотрена настройка параметра “Параметр функциональной опции” поскольку ее описание лучше включить в статью по функциональным опциям.
Читайте также: