Как правильно получать дополнительные сведения в запросе 1С, если значение равно Ложь?

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

Разберем причину проблемы

Основная причина кроется в архитектуре хранения дополнительных сведений. В системе 1С данные в регистре сведений хранятся оптимизированным способом. Если пользователь устанавливает значение «Ложь» (для булевых типов), число «0», пустую строку или пустую ссылку, запись в регистре зачастую физически не создается. Система просто удаляет существующую запись, так как считает, что «пустое» значение не требует хранения.

Когда вы пишете запрос с ЛЕВОЕ СОЕДИНЕНИЕ и указываете фильтр ГДЕ ДополнительныеСведения.Свойство = &Свойство, происходит следующее:

1. Система находит документы, у которых есть запись в регистре.
2. Если для документа записи нет (значение подразумевается как «Ложь»), левое соединение возвращает NULL.
3. Условие в ГДЕ сравнивает NULL со значением параметра &Свойство. Результат сравнения — «ложь», и запись отсекается.

Таким образом, ваше левое соединение фактически превращается во внутреннее, скрывая все документы с «пустыми» значениями.

Решение проблемы: перенос условия в секцию соединения

Чтобы увидеть все документы, включая те, у которых свойство не заполнено, нам необходимо перенести условие фильтрации из блока ГДЕ непосредственно в блок ПО при описании соединения. В этом случае проверка свойства выполнится до того, как система отсечет записи с NULL.

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

ВЫБРАТЬ
    РеестрДокументов.Ссылка КАК Ссылка,
    ДополнительныеСведения.Свойство КАК Свойство,
    ЕСТЬNULL(ДополнительныеСведения.Значение, Ложь) КАК Значение
ИЗ
    РегистрСведений.РеестрДокументов КАК РеестрДокументов
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДополнительныеСведения КАК ДополнительныеСведения
        ПО (ДополнительныеСведения.Объект = РеестрДокументов.Ссылка 
            И ДополнительныеСведения.Свойство = &Свойство)
ГДЕ
    ТИПЗНАЧЕНИЯ(РеестрДокументов.Ссылка) = ТИП(Документ.РеализацияТоваровУслуг)

Разберем шаги выполнения

Давайте проанализируем, что именно изменилось:

1. Мы переместили условие И ДополнительныеСведения.Свойство = &Свойство внутрь скобок оператора ПО. Это критически важный момент для работы ЛЕВОГО СОЕДИНЕНИЯ.
2. Мы использовали функцию ЕСТЬNULL. Теперь, если для документа нет записи в регистре (так как свойство не заполнено), запрос подставит значение Ложь, которое мы передали вторым аргументом в функцию.
3. В секции ГДЕ мы оставили только фильтрацию по типу документа, что позволяет нам получить полную выборку объектов для анализа.

Важные рекомендации при работе с дополнительными сведениями

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

• Целостность данных: Помните, что стандартные механизмы БСП при работе с доп. сведениями автоматически управляют записями. Если в вашей базе есть записи, где значение физически записано как «Ложь», это может быть результатом прямого изменения данных или нестандартной обработки. В идеале таких записей быть не должно.
• Производительность: Если объем данных в регистре ДополнительныеСведения огромен, левое соединение может работать медленно. В таких случаях можно сначала отобрать документы во временную таблицу, а затем соединять её с регистром.
• Проверка результата: Если после правки запроса некоторые записи все равно кажутся пустыми или ведут себя странно, проверьте через консоль запросов, что именно возвращает ДополнительныеСведения.Значение для конкретной ссылки, чтобы убедиться, что проблема не в передаваемом параметре &Свойство.

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