Не провоцируйте СКД, или пример "как не надо"
В данной заметке разберём конкретный пример конструкции, которую лучше не использовать в запросах, чтобы не удивляться результату СКД.
СКД — это волшебная система. Каждый раз удивляемся, сколько можно сэкономить времени, с умом используя её возможности. Однако, как известно, есть у неё и разные «особенности». И их тоже лучше знать.
Возьмём, к примеру, такую ситуацию.
ВЫБРАТЬ
Валюты.Ссылка КАК Ссылка,
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = "" ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
ИЗ
Справочник.Валюты КАК Валюты
Есть справочник с наименованием и кодом. Мы хотим вывести его элементы. И по каждому выводим колонку «ОшибкаЗаполнения» (булево). Колонка будет содержать значение Истина, когда Наименование или Код пустое.
Результат выполнения:
Вроде всё хорошо. Но предположим, что нам нужно теперь в полученном отчёте вывести только те записи, у которых «Ошибка заполнения» = Нет.
Накладываем отбор и выводим:
Неожиданный результат, верно?
Но для начала на таком простом запросе лучше самому попробовать добавить условие отбора. Не будем сейчас соревноваться в красоте запроса, а просто представим себя на месте СКД. Как бы она подставила наш отбор «Ошибка заполнения» = Нет?
-
Выносим поле в секцию ГДЕ:
ГДЕ Валюты.Наименование = "" ИЛИ Валюты.Код = "" -
Оборачиваем в скобки:
ГДЕ (Валюты.Наименование = "" ИЛИ Валюты.Код = "") -
Сравниваем с значением отбора:
ГДЕ (Валюты.Наименование = "" ИЛИ Валюты.Код = "") = ЛОЖЬ
Получаем такой текст запроса. Это то, чего мы ожидаем увидеть от СКД.
ВЫБРАТЬ
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = "" ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
ИЗ
Справочник.Валюты КАК Валюты
ГДЕ
(Валюты.Наименование = "" ИЛИ Валюты.Код = "") = ЛОЖЬ
Теперь же нам нужно отловить «реальный» текст запроса. Для этого добавляем в наш отчёт кусочек примитивного кода:
Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, КомпоновщикНастроек.ПолучитьНастройки());
НаборДанных = МакетКомпоновки.НаборыДанных.Получить(0);
КонецПроцедуры
Ставим точку останова в конце процедуры, запускаем отладчик, переоткрываем отчёт и снова формируем его с наложенным отбором «Ошибка заполнения» = Нет
В результате в переменной НаборДанных можно увидеть свойство «Запрос».
Мы для наглядности в самом тексте запроса заменили автоматически генерируемый параметр на его значение, которое можно увидеть в переменной МакетКомпоновки.ЗначенияПараметров.
ВЫБРАТЬ
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = "" ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
ИЗ
Справочник.Валюты КАК Валюты
ГДЕ
(Валюты.Наименование = "" ИЛИ Валюты.Код = "" = ЛОЖЬ)
В чём ошибка?
Если вернуться к нашим шагам наложения условия, можно понять, что СКД пропустила шаг 2.
-
Выносим поле в секцию ГДЕ:
ГДЕ Валюты.Наименование = "" ИЛИ Валюты.Код = "" -
Оборачиваем в скобки:
ГДЕ (Валюты.Наименование = "" ИЛИ Валюты.Код = "") -
Сравниваем с значением отбора:
ГДЕ (Валюты.Наименование = "" ИЛИ Валюты.Код = "") = ЛОЖЬ
Выходит, что логика СКД была такая:
-
Выносим поле в секцию ГДЕ:
ГДЕ Валюты.Наименование = "" ИЛИ Валюты.Код = "" -
Сравниваем с значением отбора:
ГДЕ Валюты.Наименование = "" ИЛИ Валюты.Код = "" = ЛОЖЬ
Однако, без оборачивания в скобки, СКД полностью меняет смысл условия. В результате мы и видим такой результат. В поле формула отрабатывает нормально, но вот фильтрация работает неверно.
Интересно, что если данное поле убрать из запроса и вынести в вычисляемые поля СКД, то такой ошибки не будет.
Но что, если вынести поле в вычисляемые для нас не выход? Всё просто, применяем другую конструкцию и вместо:
Валюты.Наименование = ""
ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
пишем
ВЫБОР
КОГДА Валюты.Наименование = "" ИЛИ Валюты.Код = ""
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ КАК ОшибкаЗаполнения
Не так красиво, но зато теперь СКД точно не накосячит, ведь просто подставит сравнение к концу поля.
Возможно, Вам больше понравится иначе изменить условие запроса, но в данный момент это не принципиально. Главное, при написании подобных запросов помнить про эту «особенность». Ведь лучше не провоцировать СКД.
Замечено давненько. Но сейчас протестировано на платформах: 8.3.12.1595, 8.3.14.1779.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструментарий разработчика Роли и права Запросы СКД Разработчик Руководитель проекта 1С:Предприятие 8 Платные (руб)
Инструменты для разработчиков 1С 8.3 и 8.5: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.
16500 руб.
02.09.2020 285588 1606 423
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Как решить проблему с отборами по полям СКД, когда с одинаковым отбором Отчет показывает одно, а Консоль запросов другое.
16.06.2026 6365 sapervodichka 45
Инструментарий разработчика СКД Разработчик 1С 8.3 Бесплатно (free)
В этой статье представлен ПовелительОтчетов — общий модуль-обёртка над объектной моделью СКД, который сокращает код в 3-4 раза и делает его читаемым.
29.01.2026 9436 455 shapa_pro 31
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Статья написана по результатам проведенного внутреннего обучающего вебинара для разработчиков ГК «СофтБаланс». Если осилить 25 000 знаков - задача для вас непосильная, где-то на бескрайних просторах интернета видео есть (или будет). Но здесь информация точнее. Разберем, чем запрос для СКД принципиально отличается от обычного запроса и как модифицируется в зависимости от настроек. Изучим «базовый рецепт» написания запроса для СКД, сформируем чек-лист. Полезно будет всем – от стажеров до тех. лидов. Всем, кто не снимает галку «автозаполнение» и пишет запросы для отчетов в консоли запросов – читать (вдумчиво) обязательно.
29.10.2025 27029 ovetgana 112
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Описан способ заполнения списка доступных значений для полей наборов данных и параметров в схеме компоновки данных для любых конфигураций (с использованием БСП или без).
01.07.2025 15776 krasnoshchekovpavel 7
СКД Разработчик Стажер 1С:Предприятие 8 Россия Бесплатно (free)
Несколько способов управления формами выбора параметров и отборов СКД.
10.04.2025 15207 Neti 0
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
Хорошая отчетная форма - сродни искусству. Есть какое-то невероятное эстетическое удовольствие в том, чтобы разобраться в логике учета и анализируемых показателях, спроектировать архитектуру хранения данных так, чтобы оптимально собрать эти показатели вместе с аналитическими разрезами в запросе, а затем настроить отображение так, чтобы, глядя на результат, сразу было понятно, что это за отчет и какие задачи он призван решать. Система компоновки данных - это моя первая, главная и, наверное, единственная "рабочая" любовь. Ее я использую везде, где только можно и где нельзя тоже. Хочу поделиться с вами некоторыми практическими приемами в работе с отчетами на СКД, которые, надеюсь, будут полезны.
27.02.2025 19836 ovetgana 50
СКД Разработчик 1С:Предприятие 8 Бесплатно (free)
СКД – инструмент, на базе которого в современных конфигурациях реализованы практически все отчеты. СКД используется в динамических списках, печатных формах и универсальных механизмах. Если построить простейший отчет может каждый разработчик, то с нюансами знакомы далеко не все. Расскажем о неочевидных на первый взгляд приемах, способных значительно повысить качество отчетов.
24.12.2024 17750 Akcium 17
И не решать, что использовать "хорошо", а что "плохо".
А лишь показать пример, как реагирует СКД на данный вид конструкций. И поэтому в заголовке написано: пример "как не надо". Не потому что это "плохо", а потому что приводит к конкретной проблеме.
Мы не пытаемся кого-то осуждать или хвалить. И не плюём с высока на разработчиков, которые ещё не успели перелопатить все жёлтые талмуды. Мы лишь наглядно на примере показываем, почему это может привести к ошибке.
Если кто-то из комментаторов хочет написать статью с полным и доскональным разбором документации 1С, то это будет замечательным вкладом в сообщество. Удачи!
Вот так теперь выглядит запрос, генерируемый компоновщиком:
ВЫБРАТЬ
Валюты.Ссылка КАК Ссылка,
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = ""
ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения,
Валюты.Представление КАК СсылкаПредставление
ИЗ
Справочник.Валюты КАК Валюты
ГДЕ
(Валюты.Наименование = ""
ИЛИ Валюты.Код = "") = &П Показатьp.s. Статью плюсовал в свое время. Спасибо.
Условия в тесте статьи сами по себе кривоваты, да и использование
ИЛИ в условиях я видел только в типовом коде современных конфигураций.
Если запрос пишет человек с опытом, то никаких ИЛИ в запросе не будет.
Приемлимость использования в запросах приставки ИЛИ - это другой вопрос. Но однозначно СКД должна корректно накладывать отбор, несмотря на религиозные предпочтения разработчика.
ВЫБОР
КОГДА Валюты.Наименование = ""
ТОГДА ИСТИНА
КОГДА Валюты.Код = ""
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ КАК ОшибкаЗаполнения
т.к. первое условие выбора наиболее вероятно
я не знаю кому приходит в голову такое выражение поля
Валюты.Наименование = "" ИЛИ Валюты.Код = "" КАК ОшибкаЗаполненияЗЫ: неполадка из ничего, никто так выражение поля не пишет - вы первый у кого я увидел такой нонсенс.
СКД права, что дала по рукам.
<Выражение>
<Разыменование поля> |
<Агрегатная функция> |
<Встроенная функция> |
<Операция выбора> |
<Приведение типа>[.<Разыменование поля>] |
<Значение> |
<Выражение> <Бинарная операция> <Выражение> |
<Унарная операция> <Выражение> |
( <Выражение> )
<Бинарная операция>
+ | - | * | /
<Унарная операция>
- | +
Когда же 1Сники начнут ну хоть немного документацию читать.
Не вижу ни противоречий, ни запретов использования конструкции, ни предупреждений, что СКД их сломает. При этом в вычисляемых полях они обрабатываются без проблем.
P.S.: Эта статья как раз и нужна для того, чтобы показать конструкцию, которую "не надо". Именно потому, что среднестатистический разработчик нигде не видел такого предупреждения, посему может наткнуться на особенность СКД уже в проде.
И где в вашей цитате запрет на использование логических операций в выражениях? Логические И/ИЛИ, на минуточку, тоже бинарные операции. Я-то знаю, что в грамматике запросов логические выражения описаны другим нетерминалом, но в вашей цитате ничего про него нет.
И не решать, что использовать "хорошо", а что "плохо".
А лишь показать пример, как реагирует СКД на данный вид конструкций.
И при этом использует "ИЛИ" в секции условий. На не рекомендуемый вид конструкций СКД реагирует плохо. Вот прям в первом комментарии об этом написано, а потом ещё с десяток подобных комментариев, но автор
Далее, автор пишет, что можно написать вместо ИЛИ просто "И" и будет все равно ошибка. Никто это в упор не видит и начинает втирать, что ИЛИ неоптимально. Да, неоптимально. Но речь-то не об этом! Речь о том, что СКД, накладывая условие на поле, накладывает его не совсем ожидаемым образом.
И да, это даже не ошибка СКД, в ее действиях есть логика, а для таких вещей надо применять вычисляемые поля или иные способы обхода (там же в статье).
Но почему-то все считают, что корень всех бед статьи и ее автора - применение ИЛИ...
Нет в ней логики.
Отбор накладывается по полю, а не по части поля.
Почему СКД не знает о возможности использования логических выражениях в качестве полей, вопросы к Лейбовичу =)
Навскидку, попробуйте провести эксперимент не с ИЛИ, а просто с арифметическим выражением, например
ВЫБРАТЬ ПолеРегистра + 2 КАК НаДваБольшеСКД отработает нормально или нет?
Вопрос - если скормить условие вида: "НЕ (условие1 ИЛИ условие2)"?
Я про вот это:
"Основное условие должно содержать только такие операции, которые позволяют выполнять поиск по индексу"
Можно с 8.3.6.
(11)
Действительно. Когда же начнут?
(1) А вот то что СКД не корректно воспринимает условие, в дополнение к статье стоило бы написать на v8@1c.ru
Условия могут определяться и как более сложные логические выражения, где фигурируют простые логические выражения, соединенные между собой с помощью логических операторов И, Или, Не."
Про поля выборки, то там тоже упоминаются логические выражения. Так что актуально и для них.
Я бы не хотел настаивать на точке зрения, что описанная в статье конструкция некорректна. Сам ею не раз пользовался и был уверен, что такой подход вполне допустим. Но после прочтения комментариев к настоящей статье сколько бы я ни вчитывался в документацию к платформе, я не смог разглядеть тому подтверждение. Опять же, я и не претендую на то, что всегда правильно могу прочитать и понять официальную документацию.
"Логическим выражением может быть:
● обычное выражение языка запросов, если его результат имеет логический тип"
"Выражения языка запросов описываются следующим набором правил:
<Разыменование поля> |
<Агрегатная функция> |
<Встроенная функция> |
<Операция выбора> |
<Приведение типа>[.<Разыменование поля>] |
<Значение> |
<Выражение> <Бинарная операция> <Выражение> |
<Унарная операция> <Выражение> |
( <Выражение> )
"
Но все равно конструкция вида (<Логическое выражение> И <Логическое выражение>) это тоже логическое выражение.
ВЫБРАТЬ
ПриобретениеТоваровУслуг.Ссылка КАК Ссылка,
ПриобретениеТоваровУслуг.Проведен
И НЕ ПриобретениеТоваровУслуг.ПометкаУдаления КАК Актуально
ИЗ
Документ.ПриобретениеТоваровУслуг КАК ПриобретениеТоваровУслугВполне себе рабочая конструкция.
И простите за занудство, но Ваше выражение избыточно: документ не может быть одновременно проведен и помечен на удаление. Если, конечно, кто-то накануне не работал с БД напрямую.
может :)
"Если документ помечен на удаление, то не допускается выполнение проведения этого документа. Однако допускается наличие движений у документа, помеченного на удаление, так как в 1С:Предприятии 8 понятие проведенности документа не связано жестко с наличием движений."
Хотя это наверно не про флаг "Проведен".
(18)
В данном случае, если учитывать стандарты разработки на 1с, то ошибку совершаете только Вы. И то, что Вы наткнулись на такую ошибку является следствием написанием Вами кривого запроса. Не вижу смысла с Вами продолжать беседу. Если Вы пишите криво не нужно ожидать, что программа отработает корректно
(11) Честно говоря, для меня также стало открытием, что использовать логические операторы в таком виде в секции "ВЫБРАТЬ" недопустимо. Я перечитал соответствующие разделы документации и для платформы 8.3.10, и для 8.3.14, и нигде не смог найти "разрешение" на использование оператора "ИЛИ". Почему открытие? Потому, что я хорошо помню, что где-то видел это самое "разрешение". И копнув глубже нашел его в списке изменений платформы 8.3.6:
Данная возможность не предоставлялась.
При необходимости использования логического выражения в описании поля выборки было необходимо использовать операцию выбора.
Источник:
Так что для меня теперь это открытый вопрос. Что это: ошибка в документации или неверная интерпретация нововведений в платформе?
<Логическое выражение>
<Выражение> |
(<Выражение> | <Логическое выражение>) <Операция сравнения> (<Выражение> | <Логическое выражение>) |
<Выражение> [НЕ] В [ИЕРАРХИИ] (<Список значений>) |
<Выражение> [НЕ] В [ИЕРАРХИИ](<Описание запроса>) |
<Выражение> [НЕ] МЕЖДУ <Выражение> И <Выражение> |
<Выражение> ЕСТЬ [НЕ] NULL |
<Выражение> ССЫЛКА <Имя таблицы> |
<Выражение> [НЕ] ПОДОБНО <Литерал типа СТРОКА>
[СПЕЦСИМВОЛ <Литерал типа СТРОКА>]
<Операция сравнения>
> | < | = | >= | <= | <>
<Список значений>
<Выражение>[, <Выражение> [, …]]
Логическим выражением может быть:
● обычное выражение языка запросов, если его результат имеет логический тип;
● операция сравнения двух выражений языка запросов; выполняется в соответствии с правилами сравнения значений, описанными в разделе «Правила сравнения значений»;
● оператор проверки совпадения/несовпадения значения выражения с одним из перечисленных или со значениями, содержащимися в результате другого запроса;
● оператор проверки вхождения значения выражения в диапазон;
● оператор проверки значения выражения на NULL;
● оператор проверки ссылочного значения выражения на ссылку на определенную таблицу;
● оператор проверки строкового значения наподобие шаблону.
При сравнении значений используются правила сравнения значений, описанные ниже.
Разрешения на использования логических операторов языка запросов в выражениях там нет.
Возможности языка нужно использовать правильно, а не как Вам захотелось. Вы пытаетесь отверткой забить гвоздь
книга про эксперта в ДАННОМ КОНКРЕТНОМ СЛУЧАЕ вообще не к месту упомянута. давайте будем везде запрещать писать ИЛИ - даже в справочниках где пара десятков записей. бред какой-то.
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РасчетыСЗаказчикамиОбороты.Организация,
| РасчетыСЗаказчикамиОбороты.Заказчик,
| РасчетыСЗаказчикамиОбороты.Менеджер,
| РасчетыСЗаказчикамиОбороты.Гаражка КАК Гаражка,
| СУММА(ЕСТЬNULL(РасчетыСЗаказчикамиОбороты.СуммаПриход, 0)) КАК ПоступлениеОтЗаказчика,
| СУММА(ЕСТЬNULL(РасчетыСЗаказчикамиОбороты.СуммаРасход, 0)) КАК РасходПоЗаказчику
|ПОМЕСТИТЬ ВТ1
|ИЗ
| РегистрНакопления.РасчетыСЗаказчиками.Обороты(&ДатаНачала, &ДатаОкончания, , ) КАК РасчетыСЗаказчикамиОбороты
|
|СГРУППИРОВАТЬ ПО
| РасчетыСЗаказчикамиОбороты.Организация,
| РасчетыСЗаказчикамиОбороты.Заказчик,
| РасчетыСЗаказчикамиОбороты.Менеджер,
| РасчетыСЗаказчикамиОбороты.Гаражка
|
|ИНДЕКСИРОВАТЬ ПО
| Гаражка
|;
|
|//////////////////////////////////////////////////////////// ПоказатьВ консоли запросов за выбранный период 36 записей. А СКД выдает 6 записей.
Почему-то никто не вспоминает про расширение языка запросов для системы компоновки данных, а ведь именно им управляются отборы.
Запрос из статьи можно (нужно) описать так:
ВЫБРАТЬ
Валюты.Ссылка КАК Ссылка,
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = ""
ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
ИЗ
Справочник.Валюты КАК Валюты
{ГДЕ
(Валюты.Наименование = ""
ИЛИ Валюты.Код = "") КАК ОшибкаЗаполнения}
Тогда в результате наложения отбора СКД вернет
ВЫБРАТЬ
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = ""
ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
ИЗ
Справочник.Валюты КАК Валюты
ГДЕ
(Валюты.Наименование = ""
ИЛИ Валюты.Код = "") = &П
___
Хочется здесь добавить - СКД классная штука, но как пользователю нужно понимать что программист лишь автоматизирует его труд, а не создает волшебные кнопки, так и программистам надо понимать что есть инструмент со своей спецификой, который как и многие другие инструменты не умеет вообще ВСЕ.
В СП написано:
При автоматическом заполнении доступных полей запроса выполняются следующие действия:
все поля списка выборки и их дочерние поля становятся доступными для выбора, упорядочивания, группировки, отбора и др.;
Как программист должен догадаться о создании дополнительной конструкции ГДЕ в расширении языка запросов СКД?
Я как раз и процитировал что по F1 написано. В каких курсах или книгах есть полное описание расширения языка запросов СКД? Гугл не 1с. Оптимальность кода это другой вопрос, синтаксис запроса корректен для платформы, он должен выполнятся правильно.
В (50) вы утверждаете что это из СП. ctrl + shift + F1, если что. Полного - подозреваю, что ни в каких. Просто с опытом приходит понимание того, что такое СКД, и как с ним жить. И можно хоть 1000 статей написать на тему "вот так не работает!!", я как-то более практично привык смотреть на эту проблему. Хотя тоже много глючков переловил. Мир не идеален) Максимум что можно сделать - попробовать зарегистрировать багу через поддержку.
По поводу синтаксиса - я бы вот не разделял понятия "синтаксис" и "оптимальность". Я бы объединил: все надо делать максимально просто, быстро и понятно. Попробуйте переписать ваш запрос, и посмотрите поймет ли его СКД после этого. Я понятия не имею чего там у платформы в мозгах, но подозреваю что писатели парсеров ориентировались на корректный входящий запрос, а не на то что их будут ловить подводными камнями.
Дело в том, что когда в поле присутствует логическое выражение - это выражение целесообразно написать в синтаксисе который будет наиболее верным с точки зрения СУБД.
Как я писал в начале темы, автор высосал неполадку из пальца.
Лично мне, никогда не приходило в голову в поле-выражении логического типа
не использовать Выбор ...Когда.
И не решать, что использовать "хорошо", а что "плохо".
А лишь показать пример, как реагирует СКД на данный вид конструкций. И поэтому в заголовке написано: пример "как не надо". Не потому что это "плохо", а потому что приводит к конкретной проблеме.
Мы не пытаемся кого-то осуждать или хвалить. И не плюём с высока на разработчиков, которые ещё не успели перелопатить все жёлтые талмуды. Мы лишь наглядно на примере показываем, почему это может привести к ошибке.
Если кто-то из комментаторов хочет написать статью с полным и доскональным разбором документации 1С, то это будет замечательным вкладом в сообщество. Удачи!
ВЫБОР КОГДА Валюты.Наименование <> "" И Валюты.Код <> "" ТОГДА ЛОЖЬ ИНАЧЕ ИСТИНА
Люди, вы, блин, издеваетесь ? Если НЕЛЬЗЯ такое писАть в СКД, то нужно об этом выдавать диагностику на этапе перехода от текста запроса к полям. "Недопустимое логическое выражение в условии ..." , как то так.
Да забудьте вы про красную тряпку "ИЛИ" - оно тут не виновно и речь о нем шла в контексте. Еще раз суть:
не надо нас, маленьких дурить, меняя контекст неполадки!
в условии как раз допустимо выражение без КАК
Валюты.Наименование = "" ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения
а вот в выражении поля вместо логического выражения необходимо использовать
Выбор ...Когда.
Это как таблица умножения и если вы забыли ИЛИ НЕ знали, что 2*2 = 4, то
можно, конечно, строчить гневные петиции, мол, если я пишу 2*2 = 5, то пожалуйста сообщите мне почему так нельзя.
Есть две временные таблицы.
Все таблицы имеют структуру Товар, Хакрактеристика, Количество, КоличествоРезерв
Обе заполняются из одного регистра с разными отборами.
В итоговом запросе - идет объединение двух запросов.
Первый запрос - описание
Второй запрос - это первая временная таблица
Третий запрос - это вторая временная таблица
По факт - из второй таблицы убирают Количество и КоличествоРезерв
Вот так теперь выглядит запрос, генерируемый компоновщиком:
ВЫБРАТЬ
Валюты.Ссылка КАК Ссылка,
Валюты.Наименование КАК Наименование,
Валюты.Код КАК Код,
Валюты.Наименование = ""
ИЛИ Валюты.Код = "" КАК ОшибкаЗаполнения,
Валюты.Представление КАК СсылкаПредставление
ИЗ
Справочник.Валюты КАК Валюты
ГДЕ
(Валюты.Наименование = ""
ИЛИ Валюты.Код = "") = &П Показатьp.s. Статью плюсовал в свое время. Спасибо.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1075458
Создание 10.06.19 18:00
Обновление 10.06.19 18:00
Просмотры 25553
Загрузки 0
Рейтинг
60
Комментарии 96
Код открыт Да
Рубрики СКД
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
