СКД - использование расширений языка запросов, секция ХАРАКТЕРИСТИКИ
Автоматическое и не автоматическое заполнение полей компоновки данных. Использование расширений языка запросов для СКД «{…}», секция ВЫБРАТЬ, секция ГДЕ, параметры виртуальных таблиц. Автоматизированное использование дополнительных данных в запросе: секция ХАРАКТЕРИСТИКИ.
Комментарии
Избранное
Подписка
Сортировка:
Древо
Параметры..
Условие – используется для выбора полей, по которым можно будет указывать отбор в настройках компоновки (аналогично секции ГДЕ). Отличие в том, что указанные пользователем отборы, в итоговом запросе макета компоновки будут наложены в параметрах виртуальных таблиц, а не в секции ГДЕ на уровне всего запроса.
Условие – используется для выбора полей, по которым можно будет указывать отбор в настройках компоновки (аналогично секции ГДЕ). Отличие в том, что указанные пользователем отборы, в итоговом запросе макета компоновки будут наложены в параметрах виртуальных таблиц, а не в секции ГДЕ на уровне всего запроса.
Тут есть один забавный нюанс, а именно если у вас указано больше чем 1 отбора на этой вкладке, то СКД их объединит в одну группу условий, то есть ввод сразу всех параметров станет обязательным.
Например
РегистрСведений.CR_СтатусыОбъектовАренды.СрезПоследних(, {(Контрагент = &Контрагент
И Договор = &Договор)})При попытке задать только один параметр выдаст не задано значение для параметра..
Прикрепленные файлы:
(4) В Вашем примере, полагаю, это запланированное поведение от разработчика. Либо решение "по незнанию". :) Для того, чтобы параметры не зависели друг от друга, необходимо их разделять запятыми:
Однако и такое решение оставляет желать лучшего, т.к. в этом случае пользователь может указать для отбора лишь одно значение параметра. Но не может, например, ввести список исключаемых контрагентов, либо отобрать по некоторому реквизиту контрагента так, чтобы это условие попало именно в параметры виртуальной таблицы. Поэтому для параметров виртуальных таблиц используется несколько иной синтаксис:
В таком случае пользователь сможет настраивать любой отбор по данным полям, и этот отбор в том же самом виде попадет в параметры виртуальной таблицы.
Все описанное справедливо в первую очередь при снятом флажке Автозаполнения на закладке наборов данных СКД.
Ну и прошу прощения, если я проявил излишнюю прыть, описав то, что Вы и без меня хорошо знали. :)
РегистрСведений.CR_СтатусыОбъектовАренды.СрезПоследних(, {(Контрагент = &Контрагент), (Договор = &Договор)})Однако и такое решение оставляет желать лучшего, т.к. в этом случае пользователь может указать для отбора лишь одно значение параметра. Но не может, например, ввести список исключаемых контрагентов, либо отобрать по некоторому реквизиту контрагента так, чтобы это условие попало именно в параметры виртуальной таблицы. Поэтому для параметров виртуальных таблиц используется несколько иной синтаксис:
РегистрСведений.CR_СтатусыОбъектовАренды.СрезПоследних(, {(Контрагент).* КАК Контрагент, (Договор).* КАК Договор})Все описанное справедливо в первую очередь при снятом флажке Автозаполнения на закладке наборов данных СКД.
Ну и прошу прощения, если я проявил излишнюю прыть, описав то, что Вы и без меня хорошо знали. :)
(11) Немного отличается, да. Например, я указал, что при использовании параметров не получится указать список исключений контрагенту, либо договору так, чтобы это условие попало в параметры виртуальной таблицы. Только строгое равенство одному значению. Это справедливо, если снят флаг автозаполнения и нет дополнительных инструкций для СКД.
Но при включенном автозаполнении произвольный отбор по данным полям установить можно. И если в отборе на уровне отчета дополнительно установить фильтр по одному из полей на неравенство, то такое условие все равно попадет в параметры виртуальной таблицы. Хоть мы его явное об этом и не просили.
Но при включенном автозаполнении произвольный отбор по данным полям установить можно. И если в отборе на уровне отчета дополнительно установить фильтр по одному из полей на неравенство, то такое условие все равно попадет в параметры виртуальной таблицы. Хоть мы его явное об этом и не просили.
(13)Да правильно.
Как раз об этом я пишу в статье:
"Еще несколько моментов при использовании флага «Автозаполнение»:
....
Если в запросе источника данных используется виртуальная таблица, и в настройках компоновки добавлен отбор по какому-либо измерению, в итоговом запросе макета, СКД будет накладывать отбор на параметры виртуальных таблиц"
Как раз об этом я пишу в статье:
"Еще несколько моментов при использовании флага «Автозаполнение»:
....
Если в запросе источника данных используется виртуальная таблица, и в настройках компоновки добавлен отбор по какому-либо измерению, в итоговом запросе макета, СКД будет накладывать отбор на параметры виртуальных таблиц"
(4)Спасибо за дополнение.
Я имел в виду не параметры, а отбор:
{(Контрагент).* КАК Контрагент, (Договор).* КАК Договор},
о чем пишет Денис.
Вы правы, параметры тоже можно размещать здесь и в секции "ГДЕ".
И, если они объединены логическим оператором, то их использовать возможно только совместно.
В секции "ГДЕ", такие параметры будут находиться в одной строке:
Я имел в виду не параметры, а отбор:
{(Контрагент).* КАК Контрагент, (Договор).* КАК Договор},
о чем пишет Денис.
Вы правы, параметры тоже можно размещать здесь и в секции "ГДЕ".
И, если они объединены логическим оператором, то их использовать возможно только совместно.
В секции "ГДЕ", такие параметры будут находиться в одной строке:
Прикрепленные файлы:
Множество ссылок на "справедливо для отключенного флага 'Автозаполнение'", - но ведь он почти всегда включен и поведение с ним такое же.
Да кто этот флаг вообще отключает?! Может вы просто "не умеете его готовить"?(с)
Да кто этот флаг вообще отключает?! Может вы просто "не умеете его готовить"?(с)
(10)
Полегче с выводами. Я отключаю иногда именно потому, что неплохо представляю, как он работает.
В самом простом случае я его порой отключаю при выборке данных из регистра бухгалтерии, чтобы не было среди доступных полей таких как "Субконто1" и "Субконто2", а были мои, например "Контрагент" и "Договор".
Бывает отключаю для большого пакетного запроса, когда мне хочется лучше контролировать влияние пользовательских отборов на отбор данных в различных запросах пакета, а также на расстановку параметров виртуальных таблиц.
Да кто этот флаг вообще отключает?! Может вы просто "не умеете его готовить"?(с)
Полегче с выводами. Я отключаю иногда именно потому, что неплохо представляю, как он работает.
В самом простом случае я его порой отключаю при выборке данных из регистра бухгалтерии, чтобы не было среди доступных полей таких как "Субконто1" и "Субконто2", а были мои, например "Контрагент" и "Договор".
Бывает отключаю для большого пакетного запроса, когда мне хочется лучше контролировать влияние пользовательских отборов на отбор данных в различных запросах пакета, а также на расстановку параметров виртуальных таблиц.
(14)
Можно подробней? А то можно подумать...
(14)
Мне пока фигурных скобок хватает и ограничения поля в параметрах набора данных.
В самом простом случае я его порой отключаю при выборке данных из регистра бухгалтерии, чтобы не было среди доступных полей таких как "Субконто1" и "Субконто2", а были мои, например "Контрагент" и "Договор".
Можно подробней? А то можно подумать...
(14)
Бывает отключаю для большого пакетного запроса, когда мне хочется лучше контролировать влияние пользовательских отборов на отбор данных в различных запросах пакета, а также на расстановку параметров виртуальных таблиц.
Мне пока фигурных скобок хватает и ограничения поля в параметрах набора данных.
(20) Реальных примеров, к сожалению, привести не могу, т.к. действительно редко использую отключение автозаполнения. Поэтому приведу небольшой синтетический пример для ERP 2.4. Запрос следующий:
При включенном автозаполнении на закладке наборов данных мы увидим множество полей, которые доступны для отбора. Все они - измерения используемых виртуальных таблиц: Организация, Субконто3, Характеристика, Серия и т.д. При этом действительно давать возможность пользователю устанавливать отбор по этим полям ни в коем случае нельзя, т.к. это приведет к искажению данных отчета: по Счету мы уже и так отобрали, в регистре оперативного учета нет Организации, а отбор по Субконто3 и вовсе приведет к ошибке формирования отчета. Приходится отключать доступность всех лишних полей для отбора, однако они так и остаются "висеть" на закладке наборов данных. При том лишних может быть действительно очень много, в случае, если запрос содержит множество разнообразных виртуальных таблиц - абсолютно все их измерения попадут в поля набора данных.
Пусть проблема с лишними полями отбора решена, но что если пользователю потребуется установить отбор по ресурсам? Скажем, вывести все строки отчета, где количество БУ отрицательно, либо КоличествоОУ выше некоего порога. Да, мы добавили подсказку для СКД, как нужно устанавливать отбор по полям количества в последний запрос пакета, однако это совсем не помагает: СКД все равно добавит условия по полю количества в первый запрос пакета, при том в каждый элемент объединения. В результате такой отбор опять таки исказит результат. И решить эту проблему простой установкой флажков не получится.
ВЫБРАТЬ
ХозрасчетныйОстатки.Субконто1 КАК Номенклатура,
ХозрасчетныйОстатки.Субконто2 КАК Склад,
ХозрасчетныйОстатки.КоличествоОстаток КАК КоличествоБУ,
0 КАК КоличествоОУ
ПОМЕСТИТЬ СверкаБУиОУ
ИЗ
РегистрБухгалтерии.Хозрасчетный.Остатки(, Счет В ИЕРАРХИИ (&СчетУчета), &ВидыСубконто, {(Субконто1).* КАК Номенклатура, (Субконто2).* КАК Склад}) КАК ХозрасчетныйОстатки
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Номенклатура,
ТоварыНаСкладахОстатки.Склад,
0,
ТоварыНаСкладахОстатки.ВНаличииОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
;
//////////////////////////////////////////////////////////// ПоказатьПри включенном автозаполнении на закладке наборов данных мы увидим множество полей, которые доступны для отбора. Все они - измерения используемых виртуальных таблиц: Организация, Субконто3, Характеристика, Серия и т.д. При этом действительно давать возможность пользователю устанавливать отбор по этим полям ни в коем случае нельзя, т.к. это приведет к искажению данных отчета: по Счету мы уже и так отобрали, в регистре оперативного учета нет Организации, а отбор по Субконто3 и вовсе приведет к ошибке формирования отчета. Приходится отключать доступность всех лишних полей для отбора, однако они так и остаются "висеть" на закладке наборов данных. При том лишних может быть действительно очень много, в случае, если запрос содержит множество разнообразных виртуальных таблиц - абсолютно все их измерения попадут в поля набора данных.
Пусть проблема с лишними полями отбора решена, но что если пользователю потребуется установить отбор по ресурсам? Скажем, вывести все строки отчета, где количество БУ отрицательно, либо КоличествоОУ выше некоего порога. Да, мы добавили подсказку для СКД, как нужно устанавливать отбор по полям количества в последний запрос пакета, однако это совсем не помагает: СКД все равно добавит условия по полю количества в первый запрос пакета, при том в каждый элемент объединения. В результате такой отбор опять таки исказит результат. И решить эту проблему простой установкой флажков не получится.
(24) Да, можно дать другие псевдонимы, это поможет. Также, например, как помогает в параметрах виртуальных таблиц регистров, где не нужен отбор за период, указание инструкции {&ПустаяДата}. Можно также в приведенном примере попробовать уйти от использования виртуальной таблицы, заменив ее на вложенный запрос. В целом всегда можно применить тот или иной прием, дабы "отвлечь" СКД от некоторых оптимизаций при составлении запроса.
Только я решительно не понимаю: зачем? Зачем применять различные приемы "обмана" СКД, зачем перестраивать исходный текст запроса, переименовывать поля и проводить прочие эксперименты с запросом? Ведь порой проще и красивее самому явно непосредственно в запросе указать СКД, как себя следует вести, что выбирать.
Из Ваших комментариев я сделал вывод, что если есть хоть какой-либо способ изменить запрос и настроить поля так, чтобы сохранить работоспособность отчета, и при этом не снимать флаг "Автозаполнение", то всегда следует сохранять автозаполнение. Так к чему же такая однозначность? За что Вы так не любите этот флаг, или вернее его отсутствие?
Только я решительно не понимаю: зачем? Зачем применять различные приемы "обмана" СКД, зачем перестраивать исходный текст запроса, переименовывать поля и проводить прочие эксперименты с запросом? Ведь порой проще и красивее самому явно непосредственно в запросе указать СКД, как себя следует вести, что выбирать.
Из Ваших комментариев я сделал вывод, что если есть хоть какой-либо способ изменить запрос и настроить поля так, чтобы сохранить работоспособность отчета, и при этом не снимать флаг "Автозаполнение", то всегда следует сохранять автозаполнение. Так к чему же такая однозначность? За что Вы так не любите этот флаг, или вернее его отсутствие?
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0")
|
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0
Открыть
Вакансии
Ведущий программист 1С (с функцией наставничества)
Екатеринбург
зарплата от 100 000 руб.
Полный день
Екатеринбург
зарплата от 100 000 руб.
Полный день