Полезные примеры составления схемы компоновки данных. Особенность использования механизма характеристик в скд Формируем настройки представления отчёта

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

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

Создаем отчет и настраиваем характеристики

Создадим простой отчет. В нем будет один набор данных со следующим запросом:

ТекстЗапроса = " ВЫБРАТЬ | Организации. Ссылка КАК Организация, | Организации. ИНН, | Организации. КПП |ИЗ Справочник" ;

Структура отчета будет иметь вывод только по детальным записям со всеми полями, выбираемыми в запросе. В конструкторе настройка структуры отчета будет выглядит следующим образом:

На скриншоте ниже представлен вывод отчета с текущими настройками.

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

  1. План видов характеристик "СвойстваОбъектов".
  2. Регистр сведений "ЗначенияСвойствОбъектов".

Графически связь между объектом информационной базы и его характеристиками можно изобразить по такой схеме:

Опишем схему подробнее. В регистре сведений "ЗначенияСвойствОбъектов" в измерении "Объект" содержится ссылка на элемент информационной базы, для которого сохраняется свойство. В нашем примере это ссылка на элемент справочника "Организации". Все возможные свойства объекта определяются в плане видов характеристик (ПВХ) "СвойстваОбъектов". Значение характеристики, сохраняемое в регистре сведений, зависиот от доступных типов данных для элемента плана видов характеристик, записанного в измерение "Свойство". Это описание должно дать лишь общее представление о механизме доп. свойств. На практике он сложнее.

Теперь перейдем к настройке характеристик в схеме компоновки данных. Для этого запустим конструктор запроса и перейдем на вкладку "Характеристики". Здесь нужно добавить поле связи объекта информационной базы с таблицами свойств и значений свойств. Ранее мы рассматривали схему связи между объектами конфигурации для хранения доп. свойств/характеристик. В соответствии с этой информацией настройка будет следюущей:

После этого запрос набора данных дополнится инструкциями получения характеристик объектов.

" ВЫБРАТЬ | Организации. Ссылка КАК Организация, | Организации. ИНН, | Организации. КПП |ИЗ | Справочник. Организации КАК Организации | // Доп. инструкции для получения характеристик |{ХАРАКТЕРИСТИКИ | ТИП(Справочник. Организации) | ВИДЫХАРАКТЕРИСТИК ПланВидовХарактеристик. СвойстваОбъектов | ПОЛЕКЛЮЧА Ссылка | ПОЛЕИМЕНИ Наименование | ПОЛЕТИПАЗНАЧЕНИЯ ТипЗначения | ЗНАЧЕНИЯХАРАКТЕРИСТИК РегистрСведений. ЗначенияСвойствОбъектов | ПОЛЕОБЪЕКТА Объект | ПОЛЕВИДА Свойство | ПОЛЕЗНАЧЕНИЯ Значение } "

На этом все. Функционал отчета теперь позволяет выбрать поля дополнительных характеристик в отчете (поля вывода, отборы и т.д.). Но есть одно НО. Использовать эти поля в настройках отчета мы можем только в режиме 1С:Предприятия. В конфигураторе мы не можем увидеть поля характеристик, что логично, ведь характеристики вводятся пользователем и хранятся в информационной базе.

Но если есть необходимость, мы можем добавить поля характеристик, например, в отбор перед его открытием. Рассмотрим небольшой пример.

Программная работа с характеристиками

При открытии формы отчета выполним следующим программный код:

ТекущиеНастройки = КомпоновщикНастроек. Настройки; КоллекцияОтборов = ТекущиеНастройки. Отбор. Элементы; // Добавляем отбор по доп. реквизиту номенклатуры "Основной склад" . [ Основной склад] // Добавляем отбор по доп. реквизиту номенклатуры "Страна размещения" НовЭл = КоллекцияОтборов. Добавить(Тип(" ЭлементОтбораКомпоновкиДанных " ) ) ; НовЭл. ВидСравнения = ВидСравненияКомпоновкиДанных. Равно; НовЭл. ЛевоеЗначение =. [ Страна размещения] " ) ; НовЭл. Использование = Ложь ; // Добавляем отбор по доп. реквизиту номенклатуры "Связанный контрагент" НовЭл = КоллекцияОтборов. Добавить(Тип(" ЭлементОтбораКомпоновкиДанных " ) ) ; НовЭл. ВидСравнения = ВидСравненияКомпоновкиДанных. Равно; НовЭл. ЛевоеЗначение = Новый ПолеКомпоновкиДанных(" Организация. [ Связанный контрагент] " ) ; НовЭл. Использование = Ложь ;

Тогда если мы посмотрим в отбор отчета в режиме 1С:Предприятие, то увидим следующиую картину:

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

Новый ПолеКомпоновкиДанных(" Организация. [ Связанный контрагент] " ) ,

а именно на текст "[Связанный контрагент]". Если мы напишем вот так:

Новый ПолеКомпоновкиДанных(" Организация. СвязанныйКонтрагент " ) ,

то при запуске отчета СКД неправильно определит поля компоновки. В настройках поля отбора будут выделены как некорректные:

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

Новый ПолеКомпоновкиДанных(" . " )

Таким образом, мы можем устанавливать настройки отчета, даже если поля недоступны в конструкторе СКД.

Вывод

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

В статье мы рассмотрели далеко не все возможности характеристик в СКД. За рамками статьи остались такие возможности как: произвольное определение источников данных, как для свойств, так и для значений характеристик, а также отбор по владельцу для всех доступных характеристик в информационной базе и многое другое. Тема большая, есть куда расширять круг своих знания.

Порой случается, что данные в отчете нельзя получить при помощи запроса или комбинации запросов. Приходится пользоваться какими-то процедурами для сбора данных, а данные помещаются в таблицу значений. Возникает вопрос - можно ли эти данные использовать в схеме компоновки данных? Ведь СКД инструмент мощный и удобный. Оказывается, что использовать данные из таблицы значений в качестве источника данных для отчета в СКД можно и сделать это совсем не сложно. В этой статье будет показано создание такого отчета для обычных форм.
Итак, как создать отчет СКД с использованием данных из таблицы значений? Обо всем по порядку.
Первым делом открываем конфигуратор и создаем новый внешний отчет.

Открываем модуль объекта и создаем предопределенную процедуру ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)

Внутри этой процедуры будем собирать данные и формировать отчет.
В процедуре ПриКомпоновкеРезультата отключаем стандартную обработку. СтандартнаяОбработка = Ложь;
Затем формируем таблицу значений произвольным образом. Имена колонок таблицы значений должны совпадать с будущими полями набора данных в СКД.:


Для примера добавим три строки данных. Далее по шагам создаем вывод отчета.

  • Из схемы получаем настройки по умолчанию.

  • В соответствующую переменную отправляем данные о расшифровке.

  • Формируем макет с помощью компоновщика макета.

  • Передаём в макет компоновки схему, настройки и данные расшифровки.

  • Выполняем компоновку с помощью процессора компоновки. Для этого выполняем метод процессора компоновки данных Инициализировать(). В качестве параметров передаём макет компоновки данных, внешние наборы данных (тип: Структура, ключ структуры должен совпадать с именем объекта в схеме компоновки данных, значение - сформированная таблица значений), данные расшифровки.

  • Очищаем поле табличного документа.

  • Выводим результат в табличный документ.
В итоге получается следующий код:
СхемаКомпоновкиДанных = ПолучитьМакет("ОсновнаяСхемаКомпоновкиДанных" ); //Настройки = СхемаКомпоновкиДанных.НастройкиПоУмолчанию; // - Если сделать так, как показано выше(рекомендуют на некоторых ресурсах), то при изменении настроек в режиме клиента // этих изменений Вы не увидите, потому что настройки всегда будут по умолчанию. Как правильно - вариант ниже Настройки = КомпоновщикНастроек. ПолучитьНастройки(); ДанныеРасшифровки = Новый ДанныеРасшифровкиКомпоновкиДанных; КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных; МакетКомпоновки = КомпоновщикМакета. Выполнить(СхемаКомпоновкиДанных, Настройки, ДанныеРасшифровки); ВнешнийНаборДанных = Новый Структура("ПримерТаблицыЗначений" , ТЗВывод); ПроцессорКомпоновкиДанных = Новый ПроцессорКомпоновкиДанных; ПроцессорКомпоновкиДанных. Инициализировать(МакетКомпоновки, ВнешнийНаборДанных, ДанныеРасшифровки); ДокументРезультат. Очистить(); ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент; ПроцессорВывода. УстановитьДокумент(ДокументРезультат); ПроцессорВывода. Вывести(ПроцессорКомпоновкиДанных); Добавляем макет схемы компоновки. Название можем оставить по умолчанию.

Создаем набор данных. Для этого добавляем новый набор данных типа Объект. В поле Имя объекта, содержащего данных помещаем то название, которое мы указали в качестве ключа при создании структуры ВнешийНаборДанных. Затем добавляем поля. Имена должны точно совпадать с именами колонок в таблице значений. Далее можем указать допустимые значения, форматы и т.д.

Добавляем ресурсы, если это необходимо. По ним будут считаться итоги. В нашем случае это поля Количество и Сумма.

В закладке Настройки с помощью конструктора настроек формируем вариант отчета по умолчанию

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


Вот и все. Достаточно просто, не правда ли?

Получившийся отчет для примера можно скачать

В конструкторе запросов, когда он вызывается из формы настройки источника данных, для схемы компоновки данных. Есть закладка “характеристики”, использование которой не вполне ясно описано в документации. В этой статье я постараюсь объяснить, как и для чего используются характеристики в СКД.

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

Когда я впервые столкнулся с необходимостью использования этого механизма, в схеме СКД, я очень долго мучился, организовывал вложенные запросы, присоединял к основной выборке и ломал голову над тем, как учесть возможность появления новых видов свойств, которых нет на момент разработки отчета. Весь механизм свойств, будучи простым и логичным с точки зрения пользователя, не поддавался никакой нормальной обработке, пока я не разобрался с закладкой “Характеристики”.

Таблица на закладке очень капризная, либо вы введете всю строку корректно, либо откажетесь от ввода строки совсем, оставить “на потом” не до конца заполненную строку система не даст.

Итак, перейдем к конкретике. Первая колонка: Тип – здесь выбираем тип объекта, к которому привяжутся характеристики, например “СправочникСсылка.Номенклатура”

Это означает, что теперь для всех объектов указанного типа можно будет получить значения свойств.

Далее в следующей колонке Источник видов мы должны задать параметры источника видов свойств. Возможны варианты таблица м запрос , зачем нужен вариант запрос расскажу позже, сейчас выберем пункт таблица .

В колонке Виды характеристик мы должны выбрать таблицу информационной базы, в которой хранятся нужные виды характеристик, в нашем примере это будет “ПланВидовХарактеристик.СвойстваОбъектов”.

Далее, значения доступные нам для выбора в колонках Поле ключа , Поле имени и Поле типа значения , непосредственно зависят от полей выбранной нами таблицы. В Поле ключа мы выбираем Ссылка , в Поле имени Представление (именно его пользователь увидит в качестве имени реквизита), а в Поле типа соответственно ТипЗначения .

Теперь перейдем к источнику значений. Источником значений у нас будет регистр сведений “ЗначенияСвойствОбъектов”, поэтому мы выбираем в колонке Источник значений таблица , а в колонке Значения характеристик – “РегистрСведений.ЗначенияСвойствОбъектов”. В колонках Объект , Свойство , Значение , выбираем соответствующие поля регистра Объект , Свойство , Значение .

Казалось бы, на этом все. Заходим в настройки схемы, добавляем группировку по товарам, и добавляем подчиненную ей группировку, допустим по Брендам, есть у нас такое свойство.

Разворачиваем список реквизитов группировки Номенклатура и … не видим там никаких свойств:

Дело в том, что мы находимся в конфигураторе, откуда нет доступа к данным. Как же сделать нужную настройку? Удобнее всего для этого использовать консоль компоновки данных, ту что на диске ИТС, или ту что входит в подсистему “Инструменты разработчика”. Но можно и просто открыть настройку отчета в режиме предприятия.

Итак, откроем ту же настройку, но в режиме предприятия:

Как видите, у нас добавились новые “Реквизиты”, при этом свойство “Бренд ” внешне не отличается от обычных реквизитов справочника. А свойство “Вид товара ” взято в квадратные скобки, это связано с тем, что представление свойства содержит пробел.

Однако, у нас появилось и свойство “Вид договора ” которое привязано к справочнику “Договора ” и никакого отношения не имеет к “Номенклатуре “. Если не использовать в настройке “Вид договора ” то все будет работать корректно, если же его выбрать, то в результате оно окажется не заполненным, потому что ни у одного элемента номенклатуры это свойство действительно не заполнено. Но как же отфильтровать лишние свойства, чтобы они не “путались под ногами”?

Для этого нам нужно изменить настройку источника видов, в конструкторе запроса, на закладке “Характеристики”. Помните, я в начале статьи обещал рассказать, для чего нужен тип источника видов запрос ? Сейчас как раз такой случай. Меняем тип источника видов на запрос . В колонке виды характеристик нажимаем кнопочку “[…]” и открывается новое окно конструктора запросов.

Вводим туда такой запрос:

ВЫБРАТЬ
СвойстваОбъектов.Ссылка,
СвойстваОбъектов.Наименование + ” (свойство)” КАК Наименование,
СвойстваОбъектов.ТипЗначения
ИЗ
ПланВидовХарактеристик.СвойстваОбъектов КАК СвойстваОбъектов
ГДЕ
СвойстваОбъектов.НазначениеСвойства = ЗНАЧЕНИЕ(ПланВидовХарактеристик.НазначенияСвойствКатегорийОбъектов.Справочник_Номенклатура)
И (НЕ СвойстваОбъектов.ПометкаУдаления)
И (НЕ СвойстваОбъектов.Категория)

В колонках Поле ключа , Поле имени и Поле типа значения , выберем соответствующие поля выборки: Ссылка , Наименование и ТипЗначения . Получится так:

Теперь, когда мы перейдем к настройке отчета, в списке реквизитов Номенклатуры картинка изменится:

Вот теперь у товара только те свойства, которые ему назначены, более того, они теперь заметно отличаются от обычных реквизитов, благодаря приписке (свойство) , которую мы добавили к наименованию свойства в запросе.

На этом собственно и все, но многих может смутить невозможность настройки в конфигураторе. На самом деле ничего страшного нет. Достаточно сохранить настройку (или всю схему) в файл, а в конфигураторе восстановить.

Непонятные ему реквизиты конфигуратор отобразит красными крестами, как недоступные:

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

Одна из самых важных областей бизнес-софта – это отчетность. От того, насколько легко настроить под меняющиеся потребности бизнеса (и законодательства) существующий отчет или сделать новый, может зависеть (причем не в переносном смысле!) судьба бизнеса, будь то отчет для налоговой инспекции или диаграмма зависимости спроса на товары от сезона и других факторов. Мощная и гибкая система отчетности, позволяющая легко извлечь из системы нужные данные, представить их в доступном для понимания виде, позволяющая конечному пользователю перенастроить стандартный отчет так, чтобы увидеть данные в новом свете – это идеал, к которому должна стремиться каждая бизнес-система.

В платформе «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


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

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

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

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

СКУД включает:

Стандартизация

  • В России действует государственный стандарт на СКУД: ГОСТ Р 51241-98 ("Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний.").
  • В индустрии существуют устоявшиеся стандартные способы решения тех или иных задач. К ним относится использование EIA-485 (RS-485) для передачи данных между контроллерами и программным обеспечением, использование протоколов Wiegand или 1-Wire для передачи данных от УВИП к контроллеру СКУД.

Место СКУД в интеллектуальном здании

СКУД может стыковаться с другими системами автоматизации, например

  • С системой Видеонаблюдения для совмещения архивов событий систем, передачи системе видеонаблюдения извещений о необходимости стартовать запись, повернуть камеру для записи последствий зафиксированного подозрительного события.
  • С системой Охранно-пожарной сигнализации для ограничения доступа в помещения, стоящие на охране, для автоматического снятия и постановки помещений, для автоматического разблокирования УПУ в случае пожарной тревоги.

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

Ссылки

  • ГОСТ Р 51241-98 ("Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний.")

Wikimedia Foundation . 2010 .

Смотреть что такое "СКД" в других словарях:

    СКД - социально культурная деятельность СКД синтетический каучук дивиниловый Словарь: С. Фадеев. Словарь сокращений современного русского языка. С. Пб.: Политехника, 1997. 527 с. СКД сальдо конечное дебетовое бухг. фин …

    СКД РФ - СКД СКД РФ Союз концертных деятелей Российской Федерации муз., организация, РФ СКД Источник: http://news.mail.ru/news.html?396588 … Словарь сокращений и аббревиатур

    СКД-Л - синтетический каучук дивинильный на литиевом катализаторе нефт., хим. Источник: http://fs.rts.ru/content/annualreports/517/3/godovoy otchet 2009 eng.pdf … Словарь сокращений и аббревиатур

    СКД-Н - синтетический каучук дивиниловый на неодимовом катализаторе Источник: http://www.avias.com/news/2004/06/16/79836.html … Словарь сокращений и аббревиатур

    СКД - Аббр.: Симуляция Кипучей Деятельности. Так называют кафедру Социально Культурной Деятельности в Гуманитарном университете профсоюзов (ул. Фучика, 15) … Словарь Петербуржца

    СКД - самоходный комбайн двухбарабанный свеклоуборочный комбайн дисковый сверхкритическое давление синтетический каучук дивиниловый система контроля допусков система контроля доступа Совет крестьянских депутатов Союз конституционных демократов (РФ)… … Словарь сокращений русского языка

    СКД Полное название Футбольный клуб СКД Самара Основан 1989? Соревнован … Википедия

    СКД Полное название Футбольный клуб СКД Самара Основан 1989? Соревнование вторая лига, зона «Центр» 1995 15 … Википедия

    РНМЦНТ и СКД - РНМЦ НТ и СКД Республиканский научно методический центр народного творчества и социально культурной деятельности имени А. Е. Кулаковского РНМЦНТ и СКД им. А.Е. Кулаковского г. Якутск, РС(Я) http://rnmc.ykt.ru/​ г. Якутск, образование и… … Словарь сокращений и аббревиатур

    РНМЦ НТ и СКД - РНМЦНТ и СКД РНМЦ НТ и СКД Республиканский научно методический центр народного творчества и социально культурной деятельности имени А. Е. Кулаковского РНМЦНТ и СКД им. А.Е. Кулаковского г. Якутск, РС(Я) http://rnmc.ykt.ru/​ г. Якутск,… … Словарь сокращений и аббревиатур

Книги

  • , Деев В.И. Категория: Учебники для ВУЗов Серия: Университеты России Издатель: ЮРАЙТ , Производитель: ЮРАЙТ ,
  • Ядерные реакторы с водой сверхкритического давления (основы теплового расчета). Учебное пособие для вузов , Деев В.И. , Рассмотрены термодинамические циклы и тепловые схемы атомных энергоблоков с ядерными реакторами 4-го поколения ВВЭР СКД. Приводятся основные характеристики и конструкции данного типа… Категория: Учебники: доп. пособия Серия: Университеты России Издатель: