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

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

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

Вопрос №1

Ответ

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

ВЫБРАТЬ
    ТоварныеЗапасыОстатки.Товар КАК Номенклатура,
    ТоварныеЗапасыОстатки.Склад КАК Склад,
    ТоварныеЗапасыОстатки.КоличествоОстаток КАК КоличествоОстаток
ИЗ
    РегистрНакопления.ТоварныеЗапасы.Остатки(, Склад = &Склад И Товар = &Товар) КАК ТоварныеЗапасыОстатки

То есть будут наложены отборы на равенство по Складу и Товару. При этом

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

Получается достаточно жесткий вариант.

Теперь рассмотрим второй вариант запроса набора данных:

ВЫБРАТЬ
    ТоварныеЗапасыОстатки.Товар КАК Номенклатура,
    ТоварныеЗапасыОстатки.Склад КАК Склад,
    ТоварныеЗапасыОстатки.КоличествоОстаток КАК КоличествоОстаток
{ВЫБРАТЬ
    Номенклатура.*,
    Склад.*,
    КоличествоОстаток}
ИЗ
    РегистрНакопления.ТоварныеЗапасы.Остатки(, {(Склад).*, (Товар).* КАК Номенклатура}) КАК ТоварныеЗапасыОстатки
{ГДЕ
    ТоварныеЗапасыОстатки.КоличествоОстаток}

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

Уточняющий вопрос

Ответ

С этой точки зрения варианты 1 и 2 равнозначны, потому что и тот, и другой – это обязательные отборы. Просто, например, если в запросе используем таблицу справочника, то можем воспользоваться только предложением ГДЕ, поскольку для справочника в принципе не существует виртуальных таблиц. Разница получится только в том, какой запрос сгенерирует платформа и передаст для выполнения в СУБД, насколько он будет являться оптимальным. С точки зрения разработчика и отбор в предложении ГДЕ, и отбор в параметрах виртуальной таблицу – по сути фильтры, предназначенные для уменьшения объема данных, который попадет в результат запроса. И в п. 1, и в п. 2 пользователь при помощи настроек компоновки отчета не может отказаться от использования этих отборов (так как это может исказить логику отчета, которую закладывал разработчик). Поэтому я бы объединил п. 1 и п. 2 как «отборы непосредственно в тексте запроса набора данных». А п. 3 – действительно гибкий вариант.

Вопрос №2

Ответ

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

Это действие выполняется регламентным заданием ПолучениеИУстановкаИсправленийКонфигурации.