Неочевидные возможности системы компоновки данных

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

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

• С одной стороны, это один из тех инструментов, с которыми мы работаем практически с первого часа знакомства с платформой 1С:Предприятие. Традиционно мы создаем справочник, документ, регистр и отчет, который работает на системе компоновки данных.

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

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

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

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

И первый механизм, о котором я хочу рассказать – это использование характеристик в СКД.

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

Стандартные примеры использования характеристик:

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

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

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

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

• Например, у нас есть конфигурация поставщика, в которой есть справочники «Контрагенты» и «Контактные лица».

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

• И через регистр сведений реализуем сопоставление конкретной роли с конкретным контактным лицом и контрагентом – у нас появляется регистр сведений с измерениями «Контрагент», «Роль» и ресурсом «Контактное лицо».

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

• добавил необходимое ему количество ролей;

• указал контактные лица, которые эти роли занимают;

• и в отчете мог увидеть, на какой роли какое контактное лицо находится.

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

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

• В данном случае мы расширяем тип «СправочникСсылка.Контрагенты», и для него будем добавлять характеристики.

• Далее так же, как и в настройке характеристик для объектов, мы указываем, что это за характеристики – в данном случае наш справочник «Роли» будет играть роль объекта, который хранит в себе список возможных характеристик.

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

  • где хранится ссылка на объект;

  • где хранится ссылка на характеристику;

  • и где мы берем значение.

В тексте запроса эта настройка транслируется в инструкцию на языке расширения запросов схемы компоновки данных – в фигурных скобочках.

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

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

Мы получаем отчет, который выполняет нашу задачу.

Механизм характеристик имеет множество возможностей:

• Если у нас в базе нет конкретных таблиц, содержащих виды и значения характеристик, мы можем вместо объектов подсунуть туда текст запроса. Это еще сильнее расширяет возможности подмены характеристик на уровне отчета.

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

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

Связи источников данных. Срез / остаток на каждую дату

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

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

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

Задача:

• У нас есть информация о продажах по дням – в этот день продали столько, в этот день столько и так далее.

• Нам необходимо дополнить этот отчет информацией о том, какой в конкретный день был остаток товара на начало дня.

• И какая цена была у конкретной номенклатурной позиции.

Что мы можем сделать?

Выбираем три набора данных.

• В первом наборе данных мы выбираем наши продажи – обороты по регистру накопления «Продажи.

• Во втором наборе данных мы выбираем остатки из виртуальной таблицы «РегистрНакопления.ОстаткиТоваров.Остатки».

• А в третьем – цены и из виртуальной таблицы «РегистрСведений.ЦеныНоменклатуры.СрезПоследних».

При этом для второго и третьего набора данных мы:

• В отбор виртуальных таблиц передаем параметр «&Период» – определяем, на какой период берутся остатки и на какой период берется срез.

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

• И делаем интересную фишку – этот же параметр «&Период» добавляем как отдельное поле запроса в секции «ВЫБРАТЬ».

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

• По номенклатуре – нам интересен остаток конкретного товара или цены конкретного товара.

• По периоду.

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

Итого, у нас получается отчет, который показывает остаток и цену на каждую дату.

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

Связи источников данных. Своя иерархия

Второй кейс применения связи наборов данных – это симуляция иерархии или создание некой своей иерархии.

Например, у нас есть плоский справочник пользователей, у каждого из которых заполнен реквизит «Руководитель».

Задача: нужно вывести контрагентов, за которых отвечают пользователи, дополнив этот список иерархией руководителей до самого главного в фирме.

Аналогичным образом выбираем:

• основные данные, которые нам нужны – поля «Ссылка» и «Ответственный» из справочника «Контрагенты»;

• и данные, по которым мы будем строить иерархию – в данном случае мы берем «Ссылку» и «Руководителя» из справочника «Пользователи».

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

Настраиваем связи наборов данных:

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

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

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

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

Пример построенной иерархии вы можете видеть на слайде.

У этого метода есть несколько своих особенностей:

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

• Иерархия на связях источников данных не срабатывает на регистрах сведений. При подготовке к докладу в демонстрационной базе был смоделирован пример иерархии на СКД, где пользователь и руководитель хранятся в регистрах сведений, и по результатам эксперимента было обнаружено, что такая иерархия не работает – здесь есть недоисследованный нюанс, про который нужно помнить.

Поля, вычисляемые поля, параметры

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

Первый кейс

Первый интересный кейс – это поля-заглушки.

Например, у нас есть отчет по продажам, в котором есть:

• Номенклатура,

• Контрагент

• Сумма – или кто что на какую сумму покупает.

Задача: Нам необходимо добавить в этот отчет поле «Количество», чтобы смотреть, сколько уникальных номенклатурных позиций приобрел конкретный контрагент.

С одной стороны, можно добавить в запрос агрегатную функцию КОЛИЧЕСТВО(РАЗЛИЧНЫЕ Контрагент). Но тогда у нас исчезнет доступ к стандартному механизму СКД – возможности расшифровки отчета по контрагентам, а это все-таки хочется сохранить.

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

Затем на закладке «Ресурсы» указываем агрегатную функцию Количество(Различные), но уже отсылаясь к другому полю – к полю «Номенклатура».

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

Второй кейс

Второй вариант использования настройки полей – это параметры редактирования.

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

• Сможем передавать параметры в форму выбора этого объекта.

• Связывать параметры выбора с другим полем или параметром.

• Предоставлять отдельную форму выбора какого-то значения в отбор или параметр.

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

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

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

Здесь показана настройка.

Здесь показан результат.

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

• И справа вариант, когда связи параметров выбора настроены. Мы страхуем пользователя от ошибки, что он выберет контрагента одного, а договор другой, и получит очевидно пустой отчет, потому что таких данных в базе нет.

Кроме этого:

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

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

• Плюс, если мы привязываемся к плану видов характеристик, мы можем ограничить тип выбираемого значения. Например, можно жестко ограничить тип значения в запросе конструкцией: «ВЫРАЗИТЬ …. КАК Справочник.Контрагенты». Вместо этого можно настроить ограничение типа в настройках вывода – в параметрах редактирования. Тогда отчет становится более гибким – если у нас поменяется характеристика или тип, отчет продолжит работать без дополнительного внимания со стороны разработчика.

Агрегатные функции

Еще один блок — это агрегатные функции.

В дополнение к стандартным агрегатным функциям, которые доступны в запросе – Сумма, Количество, Среднее, Максимум, Минимум – система компоновки данных предоставляет множество дополнительных агрегатных функций.

Для расчета ресурсов в разрезе различных группировок есть еще дополнительные четыре функции:

• Вычислить() – на данный момент устарела;

• ВычислитьВыражение();

• ВычислитьВыражениеСГруппировкойМассив();

• ВычислитьВыражениеСГруппировкойТаблицаЗначений().

Каким образом можно использовать агрегатные функции?

• Во-первых, агрегатные функции используются на закладке «Ресурсы» в конструкторе схемы компоновки данных.

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

Допустим, у нас имеется отчет по продажам: Контрагент, Номенклатура, Количество, Сумма. Нам необходимо:

• Для каждой строки Номенклатуры в группировке «Контрагент-Номенклатура» вывести итоги по Контрагенту.

• Для каждой Номенклатуры вывести, сколько Контрагентов ее приобретали.

• Для каждого Контрагента в ячейке через запятую вывести список Номенклатуры, которую он приобретал.

Все это мы сделаем с помощью агрегатных функций системы компоновки данных – без использования конфигуратора.

Итоги по Контрагенту в группировке по Номенклатуре.

Здесь мы используем функцию «ВычислитьВыражение()», которая позволяет вычислять агрегатную функцию в разрезе конкретной группировки – например, вычислим сумму продаж в разрезе контрагента:

ВычислитьВыражение("Сумма([Сумма Оборот])", "Контрагент")

Получим отчет, в котором у нас два ресурса:

• «СуммаОборот» – на уровне группировки «Номенклатура» рассчитывается в разрезе номенклатуры;

• «СуммаПоКонтрагенту» – наследуется из итогов по Контрагенту.

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

Такой отчет мы максимально просто смогли получить нажатием пары кнопок в конструкторе.

Популярность номенклатуры – для каждой Номенклатуры вывести, сколько Контрагентов ее приобретали.

Здесь мы тоже делаем дополнительное поле и рассчитываем его как агрегатную функцию «Количество(Различные Контрагент)».

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

Вот так выглядит итоговый отчет с количеством контрагентов по каждой номенклатуре.

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

А если мы будем использовать функцию
«СоединитьСтроки(Различные Номенклатура, ", "»
будут выведены только уникальные позиции.

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

Кроме этого:

• Есть агрегатная функция «Каждый», которая позволяет проверить, все ли элементы в группировке удовлетворяют какому-то условию.

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

• Есть множество различных статистических функций: стандартное отклонение, дисперсия и ABC-классификация (ее параметры можно задавать на уровне функции).

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

Библиотека стандартных подсистем

Заключительный блок доклада касается «Библиотеки стандартных подсистем».

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

У нас есть две подсистемы, которые отвечают за работу с отчетами:

• Варианты отчетов.

• Рассылки отчетов.

Подсистема «Варианты отчетов» позволяет:

• Более удобно использовать форму отчета, добавляя на нее дополнительные функции.

• Формирует отчеты в фоне. Стандартно в отчетах мы нажимаем кнопку «Сформировать», у нас идет синхронный вызов на сервер, и пока отчет формируется, приложение висит. Для больших отчетов это не очень удобно, но благодаря подсистеме «Варианты отчетов» пользователь нажимает кнопку, запускает фоновое задание, и может в это время переключаться по вкладкам и спокойно заниматься своими делами. А потом возвращается посмотреть отчет.

• Можем выводить отчеты в панели отчетов – обычно в системах отчетов много, в каждой подсистеме есть своя панель отчетов, где мы видим большой список.

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

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

Различия форм отчета. При включении отчета в подсистему «Варианты отчетов» у нас добавляются:

• команды для сворачивания и разворачивания группировок;

• для быстрой отправки отчета по электронной почте;

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

Универсальный отчет. Ранее рассматривали несколько примеров отчета, которые брали информацию из регистра накопления «Продажи» с полями «Контрагент», «Номенклатура», «Количество», «Сумма».

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

Панели отчетов.

• Можно сгруппировать отчеты в панели для своей подсистемы, которую вы разрабатываете в расширении.

• Либо доработать конфигурацию – добавить в нее одну команду и получить там эту панель отчетов.

Рассылка отчетов. Это отдельная подсистема, которая позволяет автоматически сформировать отчет по кнопке или по расписанию и отправить его пользователям.

Причем в последней версии «Библиотеки стандартных подсистем» 3.1.9 добавилась возможность интегрировать отчет в текст электронного письма. Таким образом можно смотреть отчет, не открывая вложения.

Это выглядит примерно так.

Я давно пользуюсь рассылками отчетов, и последние изменения значимо увеличили читаемость отчетов.

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

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

И опять же это встроено в «Библиотеку стандартных подсистем» 3.1.9, и эти возможности уже появились в «Бухгалтерии предприятия» и «ЗУП».

Заключение

Итого, о каких возможностях мы поговорили:

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

• Сложные связи наборов данных. Построение среза последних на каждую дату и построение своей искусственной иерархии.

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

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

• Возможности БСП в части отчетов. Отчет можно подключить к подсистеме «Варианты отчета» и включить в панель отчетов практически автоматически, заполнив свойство «Хранилище вариантов отчета». Далее пользователи получат возможность удобно и гибко с этим отчетом работать, а также по расписанию отправлять его себе на электронную почту.

Для всех примеров, которые мы сегодня рассмотрели, я подготовил демонстрационную конфигурацию – ее исходный код в формате EDT выложен в репозитории на GitHub. Кроме этого, на странице релизов есть выгрузка базы в формате DT – если кому-то так удобнее, можно оттуда загрузить.

Вопросы и ответы

Часто в схемах отчетов на закладке «Ресурсы» могут быть масштабные расчеты с помощью функций СКД. Как вы их редактируете?

Ctrl+C, VSCode, Ctrl+V и редактирую.

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

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

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

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

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

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

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

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

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

Планируется ли в дальнейшем развитие СКД? Потому что единственное, что помню, добавили вещей для ЗУП и галочку «Группировать».

По планам, к сожалению, сориентировать не могу. Если у вас есть конкретные предложения, особенно если конкретные предложения, требующиеся для внедрения, для конкретных кейсов, то у нас есть telegram-аккаунт @platform_suggestions. Каждую пятницу он публикует призыв писать пожелания в канал 1С-разработчиков. Пишите туда. И я точно знаю, что разработчики платформы с обратной связью из этого канала очень плотно работают, собирают, и многие пожелания включаются в предстоящие версии. Но конкретных планов из тех, что анонсированы, я не помню.

Если при выводе иерархии пользователь на четвертом уровне выберет первый, зациклит, как отчет отреагирует?

Я не проверял. Скорее всего, прервется. По-моему, должен храниться стэк тех элементов, которые уже были выведены в иерархию, скорее всего, он просто прервется и остановит вывод. Но конкретных экспериментов сам не проводил.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.