Почему не работает программный отбор в списке заказов 1С и как это исправить

← На главную

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

Анализ исходного кода и выявление проблемы

Рассмотрим ситуацию, когда в коде прописана установка нескольких фильтров. В нашем примере часть условий (по стадии покупки и ответственному) отрабатывает корректно, а блок с булевыми значениями (Самовывоз, Бронь, Обработан) — нет.

Типичный код установки отбора выглядит следующим образом:


ДокументСписок.Отбор.СтадияПокупки.Использование = Истина;
ДокументСписок.Отбор.СтадияПокупки.ВидСравнения = ВидСравнения.ВСписке;
ДокументСписок.Отбор.СтадияПокупки.Значение = Список;

// Блок, который часто вызывает затруднения
ДокументСписок.Отбор.Самовывоз.Использование = Истина;
ДокументСписок.Отбор.Самовывоз.ВидСравнения = ВидСравнения.Равно;
ДокументСписок.Отбор.Самовывоз.Значение = Ложь;

ДокументСписок.Отбор.Ответственный.Использование = Истина;
ДокументСписок.Отбор.Ответственный.ВидСравнения = ВидСравнения.НеРавно;
ДокументСписок.Отбор.Ответственный.Значение = Менеджер;

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

Решение 1: Инверсия логики сравнения

Одной из самых неочевидных особенностей платформы 1С является обработка пустых значений в базе данных. Если поле в таблице БД может принимать значение NULL (например, если оно добавлено позже или является результатом левого соединения в запросе), то фильтр ВидСравнения.Равно со значением Ложь может не сработать для записей, где значение физически не определено.

Попробуем изменить подход: вместо того чтобы искать записи, где флаг выключен (равен Ложь), мы исключим те, где флаг включен. Это заставляет SQL-движок платформы строить запрос иначе, что часто решает проблему.

Разберем пример изменения кода:


// Вместо этого:
// ДокументСписок.Отбор.Бронь.ВидСравнения = ВидСравнения.Равно;
// ДокументСписок.Отбор.Бронь.Значение = Ложь;

// Используем инверсию:
ДокументСписок.Отбор.Бронь.Использование = Истина;
ДокументСписок.Отбор.Бронь.ВидСравнения = ВидСравнения.НеРавно;
ДокументСписок.Отбор.Бронь.Значение = Истина;

Этот метод считается "золотым правилом" при работе с нестабильными отборами по булевым реквизитам в обычных формах.

Решение 2: Типизация списка значений

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

Посмотрим, как правильно подготовить список:


Список = Новый СписокЗначений;
Список.ТипЗначения = Новый ОписаниеТипов("ПеречислениеСсылка.СтадииПокупок");
// Заполнение списка...
ДокументСписок.Отбор.СтадияПокупки.Значение = Список;

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

Решение 3: Очистка пользовательских настроек и кэша

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

Для гарантированного результата рекомендуется выполнить следующие действия:

Перед установкой новых значений сбросить текущее использование всех элементов отбора: ДокументСписок.Отбор.Сбросить() (если требуется полная очистка).
Явно устанавливать свойство Использование = Истина для каждого значимого поля.
Проверить, не вызывается ли метод ВосстановитьДанныеФормы() или аналогичные процедуры загрузки настроек после вашего кода.

Решение 4: Принудительное обновление интерфейса

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

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


// В контексте формы
ЭлементыФормы.ДокументСписок.Обновить();

Проверка индексации полей

Проанализируем структуру метаданных. Если отбор строится по полям Самовывоз, Бронь или Обработан, убедитесь, что для этих реквизитов в конфигураторе установлено свойство Индексировать (или "Индексировать с доп. упорядочиванием").

Почему это важно: при больших объемах данных (десятки тысяч заказов) СУБД может тратить слишком много времени на поиск по неиндексированным полям. Платформа 1С в некоторых случаях имеет внутренние таймауты или ограничения на сложность запроса динамического списка, что приводит к игнорированию части условий для обеспечения хоть какой-то работоспособности интерфейса.

Итоги и рекомендации

Для стабильной работы программных фильтров в 1С придерживайтесь следующего алгоритма:

Всегда проверяйте типизацию данных в списках значений.
Для булевых полей отдавайте предпочтение условию НеРавно Истина вместо Равно Ложь.
Убедитесь, что поля, по которым идет отбор, индексированы в метаданных документа.
Если отбор устанавливается в процедуре ПриОткрытии, убедитесь, что никакие другие системные механизмы не перезаписывают его позже (например, в ПередОткрытием или через восстановление настроек).

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