СКД (Система компоновки данных) в 1С 8

Система компоновки данных — универсальный механизм

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

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

Несмотря на то, что СКУД в 1С 8.3 можно создать интерактивно с помощью соответствующего конструктора, те же действия можно выполнять программно. Вы можете пойти с самого начала. Программно создайте схему компоновки данных, сделайте все необходимые настройки, создайте настройку варианта отчета, составьте отчет и выведите его на экран пользователю. Это более трудоемкая, но выполнимая задача.

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

Основа управляемого интерфейса 1С — СКД

В концепции управляемых форм также присутствует система компоновки данных. Все выборки, настройки условной сортировки у нас для динамических списков точно такие же, как и для ACS. Также стоит отметить, что все элементы САУ имеют возможность изготовления. Следовательно, мы можем программно создать схему, используя стандартные инструменты платформы, и, кроме того, можно работать с внешними средствами.

Описание иерархических наборов данных

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

Давайте посмотрим на пример.

Предположим, у нас есть каталог сотрудников, который содержит атрибут Supervisor, содержащий ссылку на сотрудника, который является прямым руководителем сотрудника. Документ счета-фактуры содержит атрибут Manager, который указывает сотрудника, ответственного за документ.

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

Чтобы создать такой отчет:

Давайте создадим набор данных «Документы», который получает список документов с помощью запроса:

Копировать в буфер обмена ВЫБРАТЬ
Счет-фактура.Ссылка как документ,
Номер счета,
Дата счета,
Счет подрядчика,
Сотрудник по счетам-фактурам КАК
ИЗ
Документ.Счет-фактура

Этот запрос предоставит нам документы с ответственными за них сотрудниками.

Чтобы построить иерархию, мы создадим набор данных «Зависимая иерархия». Ваш запрос будет выглядеть так:

Копировать в буфер обмена ВЫБРАТЬ
Сотрудники.Ссылка COME Employee,
Сотрудники. Менеджер
ИЗ
Список сотрудников AS Сотрудники
ГДЕ ЭТО НАХОДИТСЯ
Сотрудники. Ссылка B (& Сотрудник)

Как видите, этот запрос вернет сотрудников, перечисленных в параметре Employee Request.

Чтобы этот набор данных был получен иерархией всех менеджеров, мы опишем взаимосвязь. В конструкторе схемы компоновки данных это делается на вкладке «Ссылки».

В связи с этим мы укажем, что мы связываем набор данных иерархии сотрудников с самим собой. Исходным выражением будет «Менеджер», а целевым выражением — «Сотрудник». Следовательно, из каждой записи набора данных вы получите значение поля Supervisor, а полученное значение будет искать в поле Employee в том же наборе данных, и система будет рекурсивно извлекать все записи в иерархии. Поскольку в запросе записи получаются только для сотрудников, переданных в параметре Employee, мы укажем в отношении, что этот параметр должен использоваться, и, поскольку параметр может принимать список значений, мы указываем его в связи, устанавливая параметр относительный флажок.

Теперь вам нужно создать еще одну ссылку в схеме, которая будет указывать на то, что поле набора данных «Документы сотрудника» должно быть связано с полем иерархического набора данных.

ВАЖНО! При просмотре иерархических записей система компоновки данных выводит поля с теми же именами, что и поля, для которых иерархия завершена. Следовательно, в иерархическом наборе данных поле, с которым связан родительский набор, должно иметь то же имя, что и родительский набор. Итак, в приведенном выше примере в иерархическом наборе данных связываемое поле должно называться Employee.

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

Ответственный
Документ	Дата	Аналог
0000001	28.06.2006 14:19:00	Эльбрус
0000002	28.06.2006 14:30:32	Эльбрус
0000004	28.06.2006 14:32:06	Большаков Андрей
Тарасов
Степанов
Иванов
0000003	28.06.2006 14:30:49	Алекс 2002
0000006	28.06.2006 14:32:47	Филипенко
0000007	28.06.2006 14:34:04	Центр детского творчества
0000010	28.06.2006 14:36:36	Никитин Юрий
0000013	28.06.2006 14:45:29	Алекс 2002
0000014	28.06.2006 14:47:20	Эльбрус
0000019	28.06.2006 14:58:16	Шоппинг на улице Алексеева
Петров
0000016	28.06.2006 14:49:47	Алекс 2002
0000017	28.06.2006 14:50:23	Турмасов Марат Сергеевич
0000018	28.06.2006 14:51:36	Завод РТИ
Степанов
0000005	28.06.2006 14:32:32	Завод РТИ
0000008	28.06.2006 14:35:37	Алекс 2002
0000015	28.06.2006 14:48:09	Русская одежда
Федоров
0000009	28.06.2006 14:36:05	Шоппинг на улице Алексеева
0000011	28.06.2006 14:37:04	Шоппинг на улице Алексеева
0000012	28.06.2006 14:38:18	Автопарк № 34

СОВЕТ Чтобы предотвратить отображение полей в иерархическом наборе данных для пользователя, необходимо отключить доступность настроек для этих полей. Это делается на вкладке «Набор данных» конструктора схемы компоновки данных.

Основные настройки полей СКД.

На вкладке «Набор данных» при создании набора данных типа запроса поля создания заполняются автоматически. Как видите, поля содержат большое количество настроек.

В столбце «Поле» указано название поля, полученное из информационной базы (ИБ).
Неизменяемое значение, жестко запрограммированное для запроса. Соответствует псевдониму запроса.

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

Может ли такой дизайн нанести вред пользовательскому опыту? Да, ведь в настройках параметров отчета появятся два поля «Продукт» и «Номенклатура». Пользователю не будет ясно, чем они отличаются, хотя эти варианты выбора идентичны.
Хотя есть возможность исключить появление поля «Номенклатура», установив флажки во вкладке «Ограничение поля» — «Условие» и «Ограничение атрибута» — вкладка «Условие» во вкладке «Набор данных» в настройках поля. Кроме того, вы можете снять флажок «Автозаполнение» и заполнить все поля в конструкторе запросов на вкладке «Состав данных.

Столбец «Путь» указывает, как мы будем ссылаться на поле на всех вкладках компоновки данных. Значение, которое вы можете изменить по своему усмотрению. В имени пути разрешены пробелы, но это имя заключено в квадратные скобки. Но лучше, чтобы путь был без пробелов, так как это служебное поле. Лучше изменить заголовок, установив флажок в столбце «Заголовок».

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

вы можете использовать следующий метод для работы со столбцом «Путь». Указав путь, вы можете создать вложенные виртуальные атрибуты для элемента. Например, мы помещаем атрибут «Качество» в атрибут «Продукт». Изменим поле «Путь» атрибута «Качество» на «Продукт.Качество». Теперь во вкладке «Настройки» во вкладке «Выбранные поля» мы не найдем поля «Качество», но оно появится внутри поля «Продукт».

Рассмотрим подробнее настройки ограничения доступа. Как видите, есть две строки для ограничения доступности в столбцах «Ограничение поля» и «Ограничение атрибутов».

Столбцы, ограничивающие поля ГВС

Столбец «Ограничение поля» означает, что ограничения будут наложены на само поле. Столбец «Ограничение атрибутов» указывает, что ограничения будут наложены на вложенные атрибуты этого поля, если поле принадлежит к сложному типу данных, например, к ссылке или документу.

Каждая строка разделена на четыре других столбца. Если установлен флаг для поля или атрибутов этого поля:

• Поле будет недоступно для выбора на вкладке «Настройки» вкладки «Выбранные поля».
• Условие, поэтому они не будут доступны в качестве условия на вкладке «Настройки» на вкладке «Выбор».
• Группировать, поэтому на вкладке «Настройки» при создании нового вложения группировка на их основе будет недоступна.
• При их заказе они не будут доступны для заказа во вкладке «Настройки» во вкладке «Сортировка».

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

Item.Product + «-» + Name.Product

В этой области мы можем использовать все возможности языка ACS и получить доступ к функциям общих модулей.
Если в конфигурации есть общий модуль с именем «ForSKD» и этот модуль определяет общую функцию (с ключевым словом «Export») «GetView» с параметром «Link», то в поле «View Expression» мы будем иди Напиши:

Для SKD.Get View (Item)

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

Столбец Comparison Expression используется для определения настраиваемой сортировки. Здесь можно использовать те же конструкции, что и в поле «Отображаемое выражение».

Что ж, он все сказал, как и обещал. Если есть вопросы, пишите их в комментариях. Чтобы закрепить материал в памяти, я подготовлю тест.

В части 4 вы узнаете о расширенных настройках полей и вычисляемых полях. Вы найдете ответ на два вопроса: как передать параметры и фильтры в отчет на основе ACS без создания формы отчета и как выровнять заголовки столбцов по центру отчета. Я думаю, вы легко можете понять эти вещи!

В конце статьи вы можете посмотреть небольшой видеоролик (7 минут), который поможет вам еще эффективнее решать задачи СКУД:

Отбор «В группе»

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

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

Пример.

Если добавить в отчет из первой части статьи выбор «Номенклатура в группе ПО», то результат отчета будет выглядеть так

Выбор:	Номенклатура В группе «Программное обеспечение»

Номенклатура
Программное обеспечение
1С: Внешний вид 7.7
1С: Бухгалтерия 7.7 Базовая версия
1С: Бухгалтерия 7.7 Стандартная версия
1С: ПРОФ Бухгалтерия версия 7.7
1С: Торговля и склад 7.7 Проф
Окна
Windows XP Home Edition Русский компакт-диск
Windows XP Home Edition Русский компакт-диск UPG
Windows XP Professional Русский компакт-диск

Набор данных для проверки иерархии

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

Для этого мы создадим новый набор данных Hierarchy Check в схеме макета с текстом запроса:

Копировать в буфер обмена ВЫБРАТЬ
Справочник сотрудников Контроль иерархии сотрудников,
Сотрудники Родительский менеджер
ИЗ
Список сотрудников AS Сотрудники

ГДЕ ЭТО НАХОДИТСЯ
Сотрудники.Менеджер B (и контроль иерархии сотрудников)

Для набора данных мы определяем отношения между собой и собой. Исходное выражение «EmployeeHierarchyCheck», приемник «EmployeeHierarchyParent». Параметр ссылки CheckHierarchyEmployee с возможностью использования списка.

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

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

Итак, описанная выше взаимосвязь с выбором «Сотрудник в группе« Тарасов »будет выглядеть так:

Выбор:	Руководитель группы «Тарасов»

Ответственный
Документ	Дата	Аналог
Тарасов
Степанов
Иванов
0000003	28.06.2006 14:30:49	Алекс 2002
0000006	28.06.2006 14:32:47	Филипенко
0000007	28.06.2006 14:34:04	Центр детского творчества
0000010	28.06.2006 14:36:36	Никитин Юрий
0000013	28.06.2006 14:45:29	Алекс 2002
0000014	28.06.2006 14:47:20	Эльбрус
0000019	28.06.2006 14:58:16	Шоппинг на улице Алексеева
Петров
0000016	28.06.2006 14:49:47	Алекс 2002
0000017	28.06.2006 14:50:23	Турмасов Марат Сергеевич
0000018	28.06.2006 14:51:36	Завод РТИ
Степанов
0000005	28.06.2006 14:32:32	Завод РТИ
0000008	28.06.2006 14:35:37	Алекс 2002
0000015	28.06.2006 14:48:09	Русская одежда

Особенности работы СКД.

При использовании набора данных запрос имеет ряд функций, которые появляются
при оптимизации САУ.

• Результирующий запрос сокращается в зависимости от настройки варианта отчета,
  поскольку некоторые поля удаляются в результирующем запросе.
• Кроме того, таблицы могут быть исключены из результирующего запроса, если временные таблицы описаны в запросе и, следовательно, нигде не используются.
• То же самое верно и для наборов данных: если мы описали много наборов данных в схеме, но мы используем только несколько, система будет получать информацию только об используемых наборах данных, а остальные наборы данных будут удалены из полученной модели компоновки данных.

Могут ли эти характеристики иметь негативные последствия? Да, так как в некоторых случаях запрос не будет сформирован так, как нам хотелось бы. Следовательно, вам необходимо учитывать эти особенности при построении сложных запросов.