1с скд ограничение доступности полей реквизитов
Обновлено: 04.07.2024
В этом цикле статей мы рассмотрим особенности работы системы компоновки данных (СКД) с запросами в 1С.
При использовании подсистемы СКД 1C первое, с чем вы столкнетесь это необходимость написания запроса. Конечно, система компоновки данных умеет строить отчеты без использования запросов, например с помощью набора данных объект вы можете сделать отчет из таблицы значений. Но 90% отчетов, которые вы будете создавать с помощью СКД, потребуют написания запроса. Поэтому важно знать об особенностях работы с запросами в 1С СКД, ограничениях, способах и инструментах поиска ошибок.
Если у вас хоть раз возникал вопрос: почему запрос в консоли запросов выдает правильные данные, а в вашем отчете на СКД нет, то в этой статье вы найдете ответ.
Возможности и ограничения языка запросов при использовании в 1С СКД
В СКД можно использовать практически все возможности языка запросов 1С:
Объединения, вложенные запросы, группировка, сортировка, опции (ПЕРВЫЕ, РАЗЛИЧНЫЕ)
Параметры в запросах. При этом параметры, определенные в запросе автоматически, заполняются в 1С СКД на закладке «Параметры»
Обращение к внешним источникам данных. С помощью СКД вы можете связывать разные внешние источники данных, используя несколько наборов данных, что невозможно сделать в одном запросе. Правда, при этом нужно учитывать особенности использования наборов данных в СКД
В системе компоновки данных (СКД) недоступны:
Секция ИТОГИ. Использование данной секции в запросе добавляет в стандартную «плоскую» выборку дополнительные итоговые записи. В СКД такие записи добавляются самой подсистемой по своим правилам, поэтому данная секция для СКД неактуальна.
Предложение «АВТОУПОРЯДОЧИВАНИЕ». Обычно эта опция языка запросов редко используется, а в отчетах она практически не имеет смысла.
В СКД дополнительно с помощью расширения языка запросов 1С для СКД имеется возможность:
Подключать характеристики объектов (например, с использованием механизма плана видов характеристик). В этом случае характеристики объектов становятся как бы дополнительными полями объектов, для которых они подключены и могут использоваться в отчете в выбранных полях, условиях, группировках и т.д.
С помощью специальных конструкций можно указывать СКД, какие поля в запросе будут доступны для выборки, для использования в условиях, какие таблицы или параметры являются необязательными в запросе.
О дополнительных возможностях мы поговорим в следующем разделе.
Расширение языка запросов 1С для СКД
В предыдущем разделе мы определили, что язык запросов, используемый в 1С СКД, имеет больше возможностей, чем просто запросы, выполняемые через объект платформы «Запрос». К сожалению, упорядоченной документации по этому разделу в 1С нет. Крупицы информации разбросаны: по справке к платформе, ИТС, различным неофициальным интернет ресурсам. Я постараюсь коротко объяснить основную суть данного дополнения к языку запросов и дам ссылки на источники информации, где вы можете более подробно изучить эту тему.
Использование ограничений доступа к данным для различных объектов 1С:Предприятия 8
Этот раздел содержит информацию об особенностях использования ограничений доступа к данным, определяемых поведением различных объектов 1С:Предприятия.
О принципах функционирования ограничений доступа к данным
Основные принципы функционирования и использования ограничений доступа к данным описаны в документации 1С:Предприятия 8 и в разделе "Ограничения доступа к данным. Сведения о принципах функционирования".
Для лучшего понимания механизма проверки ограничений доступа полезно иметь в виду следующие правила:
- Каждое ограничение доступа к данным представляет собой запрос, записанный на языке запросов (с некоторыми упрощениями).
- Проверка ограничений доступа к данным выполняется для каждой записи каждой таблицы базы данных, обращение к которым происходит при выполнении запроса или в процессе манипулирования любыми объектами 1С:Предприятия.
- Для конкретной записи конкретной таблицы базы данных проверка ограничения заключается в исполнении запроса, представляющего это ограничение. Если в результате исполнения этого запроса получается непустая выборка, то считается, что доступ к записи разрешен. Если же выборка пустая, то доступ к записи запрещен.
- Если обращение к данной записи требует проверки нескольких ограничений (из разных полей и/или из разных ролей текущего пользователя), то проверяется каждое из ограничений. Результаты проверки ограничений, наложенных на доступ к разным полям, объединяются логической операцией "И". Результаты проверки ограничений, относящихся к разным ролям текущего пользователя, объединяются логической операцией "ИЛИ". Если результат полученного логического выражения равен "Истина", то доступ к записи разрешен. Иначе - доступ запрещен.
- Обращение по ссылке в ограничении имеет тот же смысл, что и обращение по ссылке в запросе, а именно, если ссылка указывает на несуществующую запись или имеет значение NULL, то значением поля по ссылке будет NULL.
- Если в ограничении доступа к данным операция сравнения использует поле табличной части, то результат сравнения равен "Истина", если табличная часть содержит хотя бы одну запись, для которой результат этого сравнения - "Истина". При использовании в одном сравнении двух полей разных табличных частей значения сравнения будет "Истина", если в декартовом произведении этих табличных частей найдется запись, для которой сравнение имеет значение "Истина".
Приведем несколько примеров.
Например, в случае простейшего ограничения вида:
ГДЕ Реквизит = &ПравильноеЗначениеРеквизита
можно считать, что для каждой записи, для которой проверяется ограничение(проверяемой записи), выполняется запрос следующего вида:
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи
ГДЕ Реквизит = &ПравильноеЗначениеРеквизита
В данной таблице доступ к записи, в которой значение реквизита "Реквизит" совпадает со значением параметра сеанса "ПравильноеЗначениеРеквизита", разрешен. К другим записям этой таблицы доступ запрещен.
Другой пример. Усложним ограничение. Допустим нужно разрешить доступ к записи таблицы "Справочник.Контрагенты" не только если ее "Реквизит" имеет "правильное значение", но и в том случае, если "правильное значение" имеет "Реквизит" родителя этой записи (1-го или 2-го уровня). В этом случае ограничение может иметь следующий вид:
Контрагенты
ИЗ Справочник.Контрагенты КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
ПО Контрагенты.Родитель = Контрагенты1.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты2
ПО Контрагенты1.Родитель = Контрагенты2.Ссылка
ГДЕ Контрагенты.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты1.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты2.Реквизит = &ПравильноеЗначениеРеквизита
Тогда запрос, который будет выполнятся в процессе проверки этого ограничения для конкретной записи справочника "Контрагенты", будет иметь вид:
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи КАК Контрагенты
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты1
ПО Контрагенты.Родитель = Контрагенты1.Ссылка
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты2
ПО Контрагенты1.Родитель = Контрагенты2.Ссылка
ГДЕ Контрагенты.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты1.Реквизит = &ПравильноеЗначениеРеквизита ИЛИ Контрагенты2.Реквизит = &ПравильноеЗначениеРеквизита
Обращения по ссылкам в запросах и ограничения доступа к данным
При установке ограничений доступа к данным важно понимать, что ограничение проверяется при обращении к записи той таблицы базы данных, к которой относится ограничение. При этом если выполняется запрос к данным с ключевым словом РАЗРЕШЕННЫЕ , то запрет доступа к некоторой записи означает, что при выполнении этого запроса будет считаться, что эта запись таблицы базы данных (не результата запроса) отсутствует.
Пусть на справочник "Контрагенты" установлено следующее ограничение доступа:
ГДЕ Ответственный = &ТекущийПользователь
а сам справочник содержит такие записи:
Ответственный
(ссылка на Справочник.Пользователи)
Пусть регистр сведений "КонтактнаяИнформация" содержит следующие записи:
КонтактноеЛицо
(ссылка на Справочник.ФизЛица)
Организация
(ссылка на Справочник.Контрагенты)
Тогда если текущим пользователем является пользователь "Иванов", то результатом запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Имя, Ответственный
ИЗ Справочник.Контрагенты
Ответственный
(ссылка на Справочник.Пользователи)
Однако, результатом следующего запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ КонтактноеЛицо, Организация
ИЗ РегистрСведений.КонтактнаяИнформация
Ответственный
(ссылка на Справочник.Пользователи)
противоречат ограничению, и поэтому считаются отсутствующими, а представление непустой ссылки на несуществующую запись равно "<Объект не найден> . ". В то же время, результатом запроса:
ВЫБРАТЬ РАЗРЕШЕННЫЕ КонтактноеЛицо, Организация.Имя КАК Имя, Организация.Ответственный КАК Ответственный
ИЗ РегистрСведений.КонтактнаяИнформация
поскольку противоречащие ограничению записи справочника "Контрагенты" считаются отсутствующими, а значениями полей "Имя" и "Ответственный" по ссылкам, указывающим на несуществующие записи, является значение NULL.
Если же необходимо по тому же признаку ограничить доступ к записям регистра сведений "КонтактнаяИнформация", то на этот регистр можно наложить ограничение вида:
ГДЕ Организация.Ответственный = &ТекущийПользователь
В этом случае результатом выполнения последнего запроса будет таблица:
Ограничения и табличные части
Ограничения доступа к данным действуют только на записи таблиц верхнего уровня и не могут ограничивать доступность записей табличных частей. С другой стороны, в тексте ограничения поля табличных частей использоваться могут. В этом случае в процессе проверки ограничения для некоторой записи будет исполнен запрос, в котором табличная часть будет соединена с таблицей из одной проверяемой записи левым внешнем соединением. Таким образом запись будет удовлетворять ограничению, если в ее табличной части найдется хотя бы одна запись, для которой условие в ограничении принимает значение "Истина".
Из соображений эффективности в ограничениях доступа к данным нельзя использовать агрегатные функции. Поэтому возможности участия в ограничениях доступа к данным каких-нибудь условий на совокупности записей табличных частей не предусмотрено. Подобная цель может быть достигнута посредством запросов, вложенных в ограничения, однако пользоваться этим необходимо с осторожностью из-за возможного снижения производительности.
Например, если документ "Накладная" содержит табличную часть "Состав", то ограничения доступа к этому документу проверяются при обращении к каждой накладной, как к единому целому и не могут разрешить доступ к какой-нибудь одной записи его табличной части "Состав", а к какой-нибудь другой запретить.
Пусть таблица "Документ.Накладная" содержит следующие записи:
Контрагент
(ссылка на Справочник.Контрагенты)
Состав (табличная часть)
В этом случае запрос, исполняемый для каждой накладной в процессе проверки следующего ограничения:
ГДЕ Состав.Количество > 50
будет иметь вид
ВЫБРАТЬ 1
ИЗ ТаблицаИзОднойПроверяемойЗаписи КАК Накладная
ЛЕВОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ Документ.Накладная.Состав КАК Состав
ПО Накладная.Ссылка = Состав.Ссылка
ГДЕ Состав.Количество > 50
Следовательно доступ будет разрешен только для записи "Трикотажная фабрика". Поэтому запрос:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Контрагент, Состав.(Номенклатура, Количество)
ИЗ Документ.Накладная
а запрос к вложенной таблице:
ВЫБРАТЬ РАЗРЕШЕННЫЕ Контрагент, Номенклатура, Количество
ИЗ Документ.Накладная.Состав
поскольку ограничение накладывается только на записи верхнего уровня, но не на записи табличных частей.
Если нужно разрешить доступ еще и к тем накладным, у которых состав пустой, то ограничение может быть модифицировано так:
ГДЕ Состав.Количество > 50 ИЛИ Состав.Количество ЕСТЬ NULL
Если же необходимо разрешить доступ только к тем накладным, у которых в табличной части "Состав" нет записей с "Количеством", превышающем 50, то в ограничении необходимо использовать вложенный запрос:
Накладная1
ИЗ Документ.Накладная КАК Накладная1
ГДЕ Накладная1.Ссылка В
(
ВЫБРАТЬ Состав1.Ссылка
ИЗ Документ.Накладная.Состав КАК Состав1
СГРУППИРОВАТЬ ПО Состав1.Ссылка
ИМЕЮЩИЕ МАКСИМУМ(Состав1.Количество) <= 50
) ИЛИ Накладная1.Состав.Количество ЕСТЬ NULL
Объекты встроенного языка
Для работы с данными в объектной технике во встроенном языке 1С:Предприятия предусмотрены специальные объекты. Например для справочника это: СправочникиМенеджер , СправочникМенеджер.<Имя справочника> , СправочникСсылка.<Имя справочника> , СправочникОбъект.<Имя справочника> , и другие.
Все операции над объектами встроенного языка 1С:Предприятия выполняются в режиме "ВСЕ" (без использования режима "РАЗРЕШЕННЫЕ"). Для успешного получения разрешенных объектов в соответствующих методах объектов необходимо указывать отборы, не противоречащие ограничениям. Например, если на чтение из регистра сведений "КонтактнаяИнформация" установлено ограничение вида:
ГДЕ Тип = &ТипКонтактнойИнформации"
то для успешного выполнения метода
необходимо установить отбор:
Если ограничение доступа сложное и не может быть сформулировано в терминах отборов, то использование выборки (метод Выбрать() ) и аналогичных оказывается невозможным. В этом случае следует использовать запросы. Проектирование разграничения доступа к данным таким образом, чтобы ограничения могли быть сформулированы в терминах отборов, позволит использовать объекты встроенного языка с максимальной гибкостью.
Виртуальные таблицы запросов
При использовании в запросах без ключевого слова РАЗРЕШЕННЫЕ виртуальных таблиц в условиях установленных ограничений доступа к данным необходимо указывать отборы, не противоречащие ограничениям не только для запроса в целом, но и для виртуальных таблиц. Например:
ВЫБРАТЬ
КонтактнаяИнформацияСрезПервых.Представление
ИЗ
РегистрСведений.КонтактнаяИнформация.СрезПоследних(, Тип = &Тип ) КАК КонтактнаяИнформацияСрезПервых
ГДЕ
КонтактнаяИнформацияСрезПервых.Тип = &Тип
Выделенный отбор по виртуальной таблице "СрезПоследних" может содержать произвольное логическое выражение, допустимое для раздела ГДЕ, использующее поля, которые присутствуют в виртуальной таблице.
Ограничения на использование реквизитов составного типа
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. Реквизиты составного типа, используемые в условиях соединений, отборах, а также для упорядочивания, должны содержать только ссылочные типы ( СправочникСсылка.[…] , ДокументСсылка.[…] и пр.). В состав их типов не рекомендуется включать никаких других нессылочных типов, например: Строка , Число , Дата , УникальныйИдентификатор , Булево , а также ХранилищеЗначения .
В противном случае производительность запросов заметно снизится. Это обусловлено особенностями физического хранения реквизитов составных типов в колонках таблиц СУБД. См. Особенности хранения составных типов данных (статья на ИТС).
1.2. В отдельных случаях, для выполнения этой рекомендации можно применить следующий подход.
Например, в документе определен реквизит Адрес составного типа, который включает ссылку на справочник Контакты и «строку» для возможности ввода в реквизит произвольных строковых значений. Вместо этого, следует предусмотреть отдельный справочник ПроизвольныеАдреса и указать его в реквизите Адрес вместо строки. При этом добавление новых элементов в справочник ПроизвольныеАдреса следует обеспечить автоматически, «незаметно» от пользователя, в момент записи документа. А удаление ненужных элементов справочника ПроизвольныеАдреса можно организовать посредством регламентного задания.
1.3. Исключение могут составлять таблицы, в которых заведомо мало данных (до 1000 записей).
2.1. Для типизированных объектов метаданных, хранящихся в информационной базе, не следует использовать составные типы ЛюбаяСсылка , СправочникСсылка , ДокументСсылка и аналогичные. Состав типов того или иного типизированного объекта должен определяться явным образом.
Исключение составляют универсальные механизмы (алгоритмы), действительно рассчитанные на работу с произвольными ссылочными объектами.
Распространенные сложности из-за избыточного использования «сильно» составных типов:
- При обращении «через точку» к реквизиту такого типа без ВЫРАЗИТЬ , выполняется неявное соединение со всеми таблицами, входящими в составной тип. Это приводит к существенной деградации производительности.
- Избыточная реструктуризация при удалении ссылочного объекта метаданных (например, значения перечисления или точки маршрута бизнес-процесса, которые также входят в тип ЛюбаяСсылка ).
- Неоправданно усложняются алгоритмы, которые избыточно должны рассчитывать на широкий набор объектов метаданных тех типов, для которых механизм не требуется в силу прикладной задачи.
- Также усложняется анализ работы механизма для внедренцев и сторонних разработчиков.
- При вводе значений в поля форм неудобно выбирать из очень большого списка типов конфигурации (когда реально нужно, например, 3-5 типов).
- Избыточный анализ и блокировки таблиц при удалении помеченных объектов, когда выполняется поиск ссылок на удаляемый.
Область применения (уточнение): управляемое приложение, обычное приложение.
2.2. В случае если составной тип массово используется в объектах какой-либо подсистемы или во всей конфигурации, то рекомендуется использовать определяемые типы.
Исключение могут составлять типы ведущих измерений регистров универсальных (библиотечных) механизмов, рассчитанных на работу с произвольными ссылочными объектами. В этом случае при необходимости сузить состав определяемого типа в конфигурации придется пересоздавать библиотечный регистр, что недопустимо. Поэтому здесь использование составных типов ЛюбаяСсылка , СправочникСсылка , ДокументСсылка и аналогичных оправданно.
Параметры могут использоваться практически в любом месте запроса и выполнять самые различные функции.
Параметры обозначаются знаком & после которого следует имя параметра.
Параметр может быть полем запроса, частью произвольного выражения поля запроса, условием для виртуальной таблицы, частью выражения в отборе запроса и так далее:
При построении запроса конструктором на вкладке “Условия” если не стоит галочка “Произвольное”, то конструктор считает что в правом значении параметр и он записывается без символа &.
Таким образом этот блок настраивается в конструкторе.
Если значение параметра не задано, то построение СКД будет невозможно и будет выдана ошибка, поэтому такие параметры называют “обязательными” или “жесткими”.
Выбрать.
Этот блок располагается в запросе типа выборка данных пакета запросов СКД в первом запросе объединения между перечнем полей и “ИЗ” и заключается в фигурные скобки.
Таким образом этот блок настраивается в конструкторе.
При автоматическом заполнении полей набора данных, для не включенных в блок расширения “ВЫБРАТЬ”, добавляются все поля списка выборки и их дочерние поля. Они становятся доступными для выбора, упорядочивания, группировки, отбора. Также добавляются поля, которые упомянуты в параметре “Условия” виртуальных таблиц как доступные для отбора.
Отбор, установленный в пользовательских настройках, будет действовать не только на основной запрос, но и на все запросы в пакете. Но это не всегда соответствует логике отчета, к примеру, если помимо отобранной номенклатуры и сумм по ней нужно выводить общую сумму продаж для сравнения. В таких случаях нам нужны специфические отборы в каждом запросе пакета.
Блок расширения “ГДЕ” может быть расположен после или вместо обычного блока “ГДЕ” в любом запросе, подзапросе, запросах объединения и заключается в фигурные скобки. Для присвоения отбору псевдонима используется конструкция “КАК”. Псевдоним нужно использовать чтобы отбор производился конструкцией расширения языка запросов, но не происходил автоматически по наименованию поля.
Если автозаполнение полей набора отключено, поля из этого блока попадают в перечень полей набора доступными только для отбора, использование дочерних полей зависит от наличия конструкции “.*”.
Если автозаполнение включено, и это поле включено в блок расширения “ВЫБРАТЬ” тогда настройки обоих блоков объединяются. Если не включено в “ВЫБРАТЬ” то поля попадают доступными для вывода, группировки, отбора и упорядочивания.
В случае если нужно дополнительно установить какое то ограничение полю, то можно вручную установить галочку в соответствующее поле перечня полей набора данных СКД.
Также в блоке “ГДЕ” вместо параметра может быть произвольное выражение с использованием конструкции ВЫБОР или параметров со страницы “Параметры” СКД. Правда в последнем случае вид сравнения необходимо указывать конкретно.
Нужно с осторожностью использовать вид сравнения МЕЖДУ поскольку:
Если параметры НачалоПериода и КонецПериода не будут заданы, то система получит документы за весь период.
Если параметры НачалоПериода и КонецПериода будут заданы, то система получит документы за указанный период.
Если какой-то один из параметров не будет задан, то система выдаст ошибку.
Один из вариантов решения это разбить МЕЖДУ на два условия чтобы система не выдавала ошибку в случае одного незаполненного параметра.
Это же замечание относится к любым выражением с использованием нескольких параметров.
Параметры виртуальных таблиц.
В параметрах виртуальных таблиц в отличие от предыдущих блоков, каждый параметр заключается в фигурные скобки. В полях относящихся к периоду название параметра ставится с &. Пример &ДатаНачала. В поле “Условие” параметры оформляются аналогично блоку “ГДЕ”.
Параметры из полей периода попадают на страницу “Параметры” СКД. Если автозаполнение включено и в поле периода параметр не вписан, параметры с именем поля периода будут автоматически созданы на странице “Параметры” СКД.
Таким образом, эти параметры заполняются в конструкторе запроса. Для открытия формы “Параметры виртуальной таблицы” нужно выбрать виртуальную таблицу в списке таблиц и нажать выделенную синим кнопку. Также тут у таблиц есть булевый реквизит “Обязательная” и числовой реквизит “Номер группы”. Если признак обязательности таблицы не установлен, то она будет добавляться в результирующий запрос только в случае, когда хотя бы одно поле из нее задействовано в компоновке. Номер группы заполняется для необязательных таблиц и обозначает группу таблиц, которые будут добавлены в результирующий запрос только, когда из этой группы таблиц задействовано хотя бы одно поле.
В параметрах виртуальных таблиц возможно совместное использование “жестких” параметров запросов и “мягких” параметров компоновки данных.
В этом примере если в настройках установлено значение параметра &НачалоПериода, то будет использоваться его значение. В противном случае в качестве значения параметра виртуальной таблицы будет использоваться значение “жесткого” параметра “&Начало”.
Если автозаполнение включено и в поля периода не вписаны “мягкие” параметры компоновки данных то параметры с именем поля периода будут автоматически созданы на странице “Параметры” СКД и текст запроса:
будет соответствовать следующему:
В этом случае “мягкие” параметры также будут иметь приоритет над “жесткими”.
Обзорный вид страницы.
На эту страницу автоматически добавляются все параметры из запроса. Можно добавлять свой параметр в для использования его в вычисляемых полях например.
Строка параметра имеет следующие реквизиты:
Таким же образом можно указать формат числа для численного параметра и длину строки для строкового.
А для того чтобы введенные значения интерпретировались в отчете как начало и конец дня следует в запросе использовать функции НачалоПериода() и КонецПериода() .
Также в примере к реквизиту “Тип” можно было в выражениях использовать функции встроенного языка запросов, особенность применения этих функций в данном месте такова, что строковые параметры функций надо брать в кавычки.
и в запросе можно было бы писать проще поскольку в параметрах уже будет содержаться начало и конец периода:
Даты начала и конца стандартного периода также содержат и время. ДатаНачала имеет время 00:00:00, а ДатаОкончания 23:59:59. Получится что пользователь выберет стандартный период в “Период” а разработчик будет использовать корректные “ПериодНачало” и “ПериодОкончание”.
В настройках варианта мы можем установить галочку “Отображать недоступные параметры”, это можно использовать если для разных вариантов мы хотим использовать разный набор параметров.
У параметров в табличной части мы можем установить значение по умолчанию для варианта, включить использование по умолчанию установив галочку слева. Нажав на кнопку, расположенную справа внизу, мы открываем окно пользовательских настроек параметра.
Если Режим редактирования установить Быстрый доступ, то параметр появится на форме.
Если у параметра “Период” представление заполнить строкой “ПеРиОд”, то вместо название будет показано содержания поля представление.
Если у отчета СКД нет формы, то платформа создаст автоматическую, на которой будут табличный документ результата, кнопки управления и быстрые пользовательские настройки.
Можно создать свою форму для отчета и вывести на нее табличное поле со всеми пользовательскими настройками. Вот так:
Для этого в созданной форме в конфигураторе вытаскиваем на форму Пользовательские настройки из Компоновщика отчета.
В некоторых случаях параметр не прост, и для его расчета нужен некий алгоритм с циклом или ветвлениями. К примеру если отчет формируем в понедельник то в отчете сравниваются продажи по дням позапрошлой и прошлой недели, а в остальные дни недели сравниваются продажи по дням прошлой и текущей недели. Получается у нас от значения дня недели текущего дня зависит сразу четыре параметра: &НачалоПрошлойНедели, &КонецПрошлойНедели, &НачалоТекущейНедели и &КонецТекущейНедели. А еще нам надо дать возможность пользователю формировать отчет как будто он сформирован вчера или неделю назад. В таком случае мы создаем реквизит формы ТекДата типа Дата. Выводим его на форму. В событии ПриИзменении() пишем.
Таким образом можно программно менять параметры из формы.
Параметры это ключевой инструмент для управления отчетом. Использование параметров дает возможность решить множество прикладных задач, таких как калькуляция на основе информации в базе и значений введенных интерактивно для конкретной калькуляции и многих других. В данной статье рассмотрены практически все относящиеся к параметрам механизмы и особенности. Рамках статьи не рассмотрен блок “Характеристики” Расширения языка запросов для СКД поскольку он не касается параметров. Не рассмотрена настройка параметра “Параметр функциональной опции” поскольку ее описание лучше включить в статью по функциональным опциям.
Читайте также: