Почему в СКД отбор по коду дополняется пробелами и как это исправить?

← На главную

При разработке отчетов в Системе компоновки данных (СКД) мы часто сталкиваемся с тем, что стандартные механизмы ведут себя не совсем очевидно. Одной из таких «особенностей» платформы является некорректная работа отбора по условию Начинается с для полей строкового типа фиксированной длины, таких как стандартный реквизит Код справочника.

Когда пользователь пытается отфильтровать данные, введя, например, БП, система автоматически дополняет введенную строку пробелами до полной длины поля (например, до 9 или 11 символов). В итоге запрос пытается найти записи, которые начинаются с БП , и не находит ничего, так как в базе данных реальные коды хранятся без этих лишних пробелов.

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

Платформа 1С:Предприятие в метаданных четко определяет тип и длину полей. Если поле Код имеет тип Строка(9), то при выполнении сравнения в запросе система может принудительно приводить сравниваемые значения к этому формату. При использовании конструктора отборов в СКД эта типизация становится препятствием: введенная пользователем строка становится Строкой(9), где недостающие символы заполняются пробелами. Сравнение "БП" = "БП " в базе данных дает ложь, отсюда и пустой результат отчета.

Решение 1: Использование пользовательского поля в настройках

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

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

Функция СокрЛП() эффективно удаляет все пробелы слева и справа, превращая строку фиксированной длины в динамическую строку. При использовании такого очищенного поля автоматическое дополнение пробелами со стороны СКД уже не создает конфликта, и отбор Начинается с начинает работать корректно.

Решение 2: Добавление вычисляемого поля в СКД

Если вы хотите, чтобы это исправление было доступно всем пользователям отчета по умолчанию, лучше реализовать его на уровне схемы компоновки данных (СКД).

Разберем это по шагам:

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

Решение 3: Модификация запроса

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

Посмотрим на пример изменения текста запроса:


ВЫБРАТЬ
    СправочникНоменклатура.Ссылка КАК Ссылка,
    СправочникНоменклатура.Код КАК Код,
    СокрЛП(СправочникНоменклатура.Код) КАК КодБезПробелов
ИЗ
    Справочник.Номенклатура КАК СправочникНоменклатура

После этого вам достаточно использовать псевдоним КодБезПробелов в качестве поля отбора. Такой подход минимизирует количество «костылей» в пользовательских настройках и гарантирует, что логика фильтрации всегда будет верной, независимо от действий пользователя.

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