Программное выполнение СКД и “ПользовательскиеНастройки”

В данной статье мы рассмотрим какие виды настроек  1C СКД существуют. Разберем как создаются элементы пользовательских настроек на форме и узнаем где хранятся настройки отчетов в СКД.

Виды настроек

У каждого отчета созданного с помощью СКД есть реквизит КомпоновщикНастроек, который в свою очередь содержит различные варианты настроек, показанные на картинке:

• Настройки – это настройки варианта отчета. Настройки, заданные по умолчанию или в конфигураторе или в режиме предприятия (при создании / изменении варианта отчета в режиме предприятия). Управлять данными настройками пользователь может через работу с вариантом отчета (Изменить вариант, Добавить вариант)
• ПользовательскиеНастройки – это список настроек из первого пункта, которыми может управлять пользователь. Особенность пользовательских настроек заключается в том, что они не изменяют вариант отчета, а применяются дополнительно («сверху») к ним. Любая пользовательская настройка связана с настройкой в варианте отчета, к которой она применяется. Эта связь с настройкой варианта отчета осуществляется через поле ИдентификаторПользовательскойНастройки. Управлять данными настройками пользователь может из формы отчета – элементы быстрых настроек доступны в форме самого отчета, элементы обычных настроек доступны через кнопку «Настройки» в отдельной форме настроек
• ФиксированныеНастройки – дополнительные настройки, которые применяются дополнительно к настройками из пункта 1. Управлять этими настройками пользователь не может. Обычно (а может и всегда) это настройки, которые задаются программно – например, при передаче отбора (или других настроек) при запуске отчета с помощью метода ОткрытьФорму.

Пользовательские настройки на форме

Когда вы создаете новый отчет на СКД и добавляете в нем форму, то система 1C спрашивает нужно ли подключить СКД в создаваемую форму:

Если этот флаг установлен, то у формы создаются 2 реквизита, создается группа для пользовательских настроек, командная панель :

Результат отчета помещается на форму, в свойствах формы настраивается связь с добавленными реквизитами и элементами:

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

Далее в этой группе система будет создавать (по умолчанию в 2 колонки) элементы пользовательских настроек:

Вы можете отключить стандартное создание пользовательских настроек, очистив свойство, отвечающее за группу пользовательских настроек. И затем с помощью метода «СоздатьЭлементыФормыПользовательскихНастроек» создать эти элементы в другой группе. Функция позволяет создать элементы настроек в произвольном количестве колонок. Пример работы можно посмотреть в отчете «ОСВ по счету».

Также вы можете производить любые (почти) настройки элементов пользовательских настроек. Например, установить обработчик изменения, установить доступность и т.п.. Пример можно посмотреть в отчете «Карточка счета» из домашнего задания.

Хранение настроек

Если в вашей конфигурации не используются какие-то специальные инструменты для хранения вариантов отчетов и пользовательских настроек, то такие настройки расположены в хранилище настроек.

По умолчанию настройка вариантов отчетов и пользовательские настройки отчетов хранятся в хранилище системных настроек. И доступны они соответственно через объекты глобального контекста ХранилищеВариантовОтчетов и ХранилищеПользовательскихНастроекОтчетов. В конфигурации можно настроить размещение настроек в отдельных хранилищах:

Эти же хранилища можно настроить отдельно для каждого отчета:

С помощью этой обработки можно посмотреть как хранятся настройки:

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

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

Немного истории

В самой первой версии платформы «1С:Предприятие 8», версии 8.0, отчеты делались так:

1. Писался один или несколько запросов на языке запросов 1С (SQL-подобный язык, подробнее о нем ниже).
2. Писался код, который переносил результаты выполненных запросов в табличный документ или в диаграмму. Код также мог делать работу, которую в запросе сделать невозможно – например, вычислял значения, используя встроенный язык 1С.

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

Постановка задачи

Задача перед командой разработки стояла такая – сделать систему создания отчетов, основанную не на алгоритмическом (т.е. через написание кода), а на декларативном подходе к созданию отчетов. И мы считаем, что задачу успешно решили. По нашему опыту, около 80% требуемой отчетности может быть реализована с помощью СКД без единой строчки кода (за исключением написания формул вычисляемых полей), по большей части — через визуальные настройки. Разработка первой версии СКД заняла около 5 человеко-лет.

Два языка

В создании отчетов задействованы два языка. Один – язык запросов, используемый для выборки данных. Второй – язык выражений компоновки данных, предназначен для записи выражений, используемых в различных частях системы, например, в настройках компоновки данных, для описания выражений пользовательских полей.

Язык запросов

Язык запросов основан на SQL и легко осваивается знающими SQL. Пример запроса: Легко видеть аналоги стандартных для SQL-запроса секций — SELECT, FROM, GROUP BY, ORDER BY. При этом язык запросов содержит значительное количество расширений, ориентированных на отражение специфики финансово-экономических задач и на максимальное сокращение усилий по разработке прикладных решений:

• Обращение к полям через точку. Если поля какой-либо таблицы имеют ссылочный тип (хранят ссылки на объекты другой таблицы), разработчик может в тексте запроса ссылаться на них через «.», при этом количество уровней вложенности таких ссылок система не ограничивает (например, ЗаказКлиента.Соглашение.Организация.Телефон).
• Многомерное и многоуровневое формирование итогов. Итоги и подитоги формируются с учетом группировки и иерархии, обход уровней может выполняться в произвольном порядке с подведением подитогов, обеспечивается корректное построение итогов по временным измерениям.
• Поддержка виртуальных таблиц. Виртуальные таблицы, предоставляемые системой, позволяют получить практически готовые данные для большинства прикладных задач без необходимости составления сложных запросов. Так, виртуальная таблица может предоставить данные по остаткам товаров в разрезе периодов на какой-то момент времени. При этом виртуальные таблицы максимально используют хранимую информацию, например, ранее рассчитанные итоги и т.д.
• Временные таблицы. Язык запросов позволяет использовать в запросах временные таблицы. С их помощью можно повысить производительность запросов, в некоторых случаях снизить количество блокировок и сделать текст запроса более легким для восприятия.
• Пакетные запросы. Для более удобной работы с временными таблицами в языке запросов поддерживается работа с пакетными запросами — таким образом, создание временной таблицы и ее использование помещаются в один запрос. Пакетный запрос представляет собой последовательность запросов, разделенных точкой с запятой («;»). Запросы в пакете исполняются один за другим. Результатом выполнения пакетного запроса, в зависимости от используемого метода, будет являться либо результат, возвращаемый последним запросом пакета, либо массив результатов всех запросов пакета в той последовательности, в которой следуют запросы в пакете.
• Получение представлений ссылочных полей. Каждая объектная таблица (в которой хранится справочник или документ) имеет виртуальное поле — «Представление». Это поле содержит текстовое представление объекта и облегчает работу создателя отчетов. Так, для документа это поле содержит всю ключевую информацию — название типа документа, его номер и дату (например, «Продажа 000000003 от 06.07.2017 17:49:14»), избавляя разработчика от написания вычисляемого поля.
• и др.

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

• ВЫБРАТЬ. В этом предложении описываются поля, которые пользователь сможет выбирать для вывода. После данного ключевого слова через запятую перечисляются псевдонимы полей из основного списка выборки запроса, которые будут доступными для настройки. Пример: {ВЫБРАТЬ Номенклатура, Склад}
• ГДЕ. Описываются поля, на которые пользователь сможет накладывать отбор. В данном предложении используются поля таблиц. Использование псевдонимов полей списка выборки недопустимо. Каждая часть объединения может содержать собственный элемент ГДЕ. Примеры: {ГДЕ Номенклатура.*, Склад }, {ГДЕ Документ.Дата >= &ДатаНачала, Документ.Дата <= &ДатаКонца}
• и др.

Пример использования расширений:

Язык выражений компоновки данных

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

Процесс создания отчета на СКД

При создании отчета нам нужно создать макет, определяющий, как данные будут отображаться в отчете. Можно создать макет, базирующийся на схеме компоновки данных. Схема компоновки данных описывает суть данных, которые предоставляются отчету (откуда получать данные и как можно управлять их компоновкой). Схема компоновки данных представляет собой базу, на основе которой могут быть сформированы всевозможные отчеты. Схема компоновки данных может содержать:

• текст запроса с инструкциями системы компоновки данных;
• описание нескольких наборов данных;
• подробное описание доступных полей;
• описание связей между несколькими наборами данных;
• описание параметров получения данных;
• описание макетов полей и группировок;
• и др.

Например, можно в качестве набора данных добавить в схему компоновки данных запрос, и вызвать конструктор запроса, позволяющий в графическом виде составить запрос произвольной сложности: Итогом запуска конструктора запросов будет текст запроса (на языке запросов «1С:Предприятия»). Этот текст можно при необходимости скорректировать вручную: Наборов данных в схеме компоновки данных может быть несколько, наборы данных могут быть связаны в макете произвольным образом, могут быть добавлены вычисляемые поля, заданы параметры отчета и т.п. Стоит упомянуть интересную особенность работы механизма запросов в 1С:Предприятии. Запросы в конечном итоге транслируются в диалект SQL, специфичный для СУБД, с которой непосредственно работает приложение. Мы вообще стараемся задействовать возможности серверов СУБД по максимуму (нас ограничивает то, что мы используем только те возможности, которые есть одновременно во всех поддерживаемых платформой «1С:Предприятие» СУБД – MS SQL, Oracle, IBM DB2, PostgreSQL). Таким образом, на уровне запроса в вычисляемых полях мы можем использовать только те функции, которые транслируются в SQL. А вот на уровне схемы компоновки данных мы уже можем добавлять пользовательские поля и использовать в них функции на встроенном языке разработки 1С (в том числе и написанные нами), что сильно расширяет возможности отчетов. Технически это выглядит так – всё, что можно транслировать в SQL, транслируется в SQL, запрос выполняется на уровне СУБД, результаты запроса помещаются в память сервера приложений 1С и СКД вычисляет для каждой записи значения вычисляемых полей, чьи формулы написаны на языке 1С.Добавление пользовательских полей В отчет можно добавить произвольное количество таблиц и диаграмм:Дизайнер отчетовОтчет во время выполнения С помощью СКД пользователь может добавлять в отчет сложные отборы (которые будут добавлены к запросу в нужных местах), условное оформление (позволяющее по-разному форматировать – шрифтом, цветом и т.д. – выводимые поля в зависимости от их значений) и многое другое. Коротко описать процесс построения и формирования отчета можно так:

• Разработчик в design time с помощью дизайнера (или в runtime с помощью кода) определяет схему компоновки данных:
  • Текст запроса/запросов
  • Описание вычисляемых полей
  • Связи между запросами (если их несколько)
  • Параметры отчета
  • Настройки по умолчанию
  • И т.д.
• Вышеописанные настройки сохраняются в макете
• Пользователь открывает отчет
  • Возможно, делает дополнительные настройки (например, меняет значения параметров)
  • Нажимает кнопку «Сформировать»
• Настройки пользователя применяются к схеме компоновки данных, определенной разработчиком.
• Формируется промежуточный макет компоновки данных, содержащий в себе инструкции, откуда получать данные. В частности, корректируются запросы, заданные в макете. Так, из запроса удаляются поля, которые не используются в отчете (это делается с целью минимизировать объем получаемых данных). В запрос добавляются все поля, участвующие в формулах вычисляемых полей.
• В дело включается процессор компоновки данных. Процессор компоновки выполняет запросы, осуществляет связь наборов данных, рассчитывает значения вычисляемых полей и ресурсов, выполняет группировку. Словом, делает все расчеты, которые не были выполнены на уровне СУБД.
• Процессор вывода данных запускает запрос на исполнение и выводит полученные данные в табличный документ, диаграмму и т.п.

Процесс формирования отчета механизмом СКД Мы стараемся минимизировать объем данных отчетов, передаваемых с сервера в клиентское приложение. При показе данных в табличном документе при открытии табличного документа мы передаем с сервера только те строчки, которые пользователь видит в начале документа. По мере продвижения пользователя по строкам документа на клиента подкачиваются с сервера недостающие данные.

Пользовательские настройки

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

• Быстрый доступ. Настройка будет выведена непосредственно в верхнюю часть окна отчета.
• Обычный. Настройка будет доступна через кнопку «Настройки».
• Недоступный. Настройка будет недоступна конечному пользователю.

Режим отображения настройки в design timeОтображение настройки в режиме «Быстрый доступ» во время выполнения (под кнопкой «Сформировать»)

Планы развития

Одно из приоритетных направлений в развитии СКД для нас – упрощение настроек пользователя. Наш опыт показывает, что для части конечных пользователей работа с пользовательскими настройками – все еще серьезный труд. Мы это учитываем и работаем в этом направлении. Соответственно, и разработчикам также станет проще работать с СКД, т.к. мы, как и раньше, хотим предоставлять единый инструментарий настройки отчетов и для разработчика, и для конечного пользователя.

Дано:

Стандартный отчёт основанный на СКД с стандартной формой сформированной конструктором.

http://screencast.com/t/3WhbQUEhaHom

Нужно при нажатии на Сформировать сформировать обычный отчет в соответствии с настройками пользователя и получить данные этого отчета в виде коллекции значений. 

ВАЖНО! Форму менять нельзя.

Решение:

Используем процедуру ПриКомпоновкеРезультата

СхемаКД=ЭтотОбъект.СхемаКомпоновкиДанных; //Можно без ЭтотОбъект т.к. процедура в модуле объекта.

КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;

//МакетКомпоновки = КомпоновщикМакета.Выполнить(ЭтотОбъект.СхемаКомпоновкиДанных, ЭтотОбъект.КомпоновщикНастроек.Настройки, ДанныеРасшифровки,, Тип(“ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений”) );

ПроцессорВывода.Вывести(ПроцессорКомпоновкиДанных);

//т.к. стандартный обработчик включен и мы не меняли схему КД то отчет сформируется стандартным алгоритмом а в ТЗ будет коллекция в соответствии с настройками пользователя.

КонецПроцедуры

Проблема:

На данном этапе в “ЭтотОбъект.КомпоновщикНастроек.Настройки” еще не заполнены значения параметров указанные пользователем на форме, не указаны значения и состояние отборов указанные пользователем.

Но они есть в ЭтотОбъект.КомпоновщикНастроек.ПользовательскиеНастройки, но  КомпоновщикМакета.Выполнить требует на вход именно Настройки.

И я не как не могу понять как заставить СКД перенести настройки пользователя в настройки или иным способом передать их КомпоновщикуМакета.

Понятно что можно в цикле обойти элементы и соответственно программно внести изменения в “Настройке” но мне кажется должен быть другой способ.

Используемые источники:

• https://wiki.programstore.ru/nastrojki-v-skd/
• https://habr.com/post/336258/
• http://1cskd.ru/2012/03/programmnoe-vypolnenie-skd-i-polzovatelskienastrojki/