Как исправить ошибку отбора по дополнительному реквизиту в УТ 11.4 и правильно настроить иерархию?

← На главную

При работе с современными конфигурациями на базе 1С:ERP, такими как Управление торговлей 11.4 или Комплексная автоматизация, разработчики часто сталкиваются с необходимостью расширения функционала через механизмы дополнительных реквизитов и сведений. Однако попытка добавить фильтр по такому реквизиту в динамический список (например, в справочнике Партнеры) часто приводит к ошибке: «Реквизит Группа у поля Ссылка не найден». Рассмотрим подробно, почему это происходит и как правильно настроить систему.

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

Разберем ситуацию: мы добавили дополнительный реквизит (например, с именем «Группа» или «Отрасль») для справочника Партнеры. В динамическом списке этого справочника используется сложный произвольный запрос. Механизм БСП (Библиотеки стандартных подсистем) динамически «подмешивает» дополнительные реквизиты в схему компоновки данных. Проблема заключается в том, как именно программный код пытается обратиться к этому полю.

Проанализируем стандартный вызов в модуле ПартнерыИКонтрагенты. Ошибка возникает в процедуре ИзменитьОтборСписок, когда система пытается сформировать путь к полю компоновки. Если код выглядит следующим образом:


ОбщегоНазначенияКлиентСервер.ДобавитьЭлементКомпоновки(ГруппаОтбора,
    ИмяРеквизитаОтбора + ".[" + Форма.ТипФильтра.Наименование + "]",
    ВидСравненияКомпоновкиДанных.Равно,
    ЗначениеОтбора);

Мы видим, что ИмяРеквизитаОтбора имеет значение Ссылка. Система пытается найти поле Ссылка.[ИмяРеквизита]. Однако в схеме динамического списка дополнительные реквизиты часто выносятся как отдельные поля верхнего уровня, а не как вложенные свойства объекта. Из-за этого платформа выдает ошибку, так как у объекта Ссылка физически нет реквизита с таким именем в метаданных.

Вариант решения 1: Исправление программного формирования пути

Как отмечают участники обсуждения, одна из проблем кроется в использовании свойства Наименование для обращения к доп. реквизиту. В некоторых релизах БСП это работает некорректно, особенно для иерархических значений или булевых типов. Попробуем изменить подход к формированию строки обращения. Вместо Наименование лучше использовать строковое представление самого объекта свойства или его идентификатор.

Рассмотрим пример корректировки кода, предложенный в обсуждении:


// Вместо старого варианта с Наименованием
// ИмяРеквизитаОтбора + ".[" + ЗначениеОтбора.Наименование + "]"

// Используем явное преобразование в строку или внутреннее имя
ИмяРеквизитаОтбора + ".[" + Строка(ЗначениеОтбора) + "]"

Важный нюанс: Если вы используете тип «Значение свойства объектов (иерархия)», то стандартное сравнение Равно может не подойти. Для того чтобы отбор включал в себя все вложенные элементы выбранной группы, необходимо использовать ВидСравненияКомпоновкиДанных.ВИерархии.

Вариант решения 2: Использование стандартных функций БСП

Чтобы избежать ошибок при обновлении конфигурации и обеспечить надежную работу отборов, проанализируем возможности программного интерфейса БСП. Вместо ручного склеивания строк вида "Ссылка.[" + Имя + "]", рекомендуется использовать специализированные функции управления свойствами.

Выясним, как получить правильное имя поля для динамического списка. В модуле УправлениеСвойствами существуют методы, позволяющие получить внутреннее имя поля свойства, которое гарантированно будет распознано СКД. Это имя обычно выглядит как ДополнительныйРеквизит_Идентификатор.

Рассмотрим алгоритм действий:

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

Особенности иерархии в справочнике «Партнеры»

Часто разработчики пытаются решить задачу классификации партнеров, создавая «папки» (группы) прямо в справочнике, как это было принято в старых версиях 1С (УТ 10.3). Однако в УТ 11.4 справочник Партнеры имеет иерархию элементов, а не групп. Проанализируем, почему это критически важно.

Для чего предназначена встроенная иерархия партнеров:

Реализация структуры «Головная организация — Филиалы».
Консолидация управленческой отчетности и взаиморасчетов по холдингу в целом.
Наследование коммерческих условий (соглашений) от родительского партнера к дочерним.

Если вы создаете элемент с названием «ПОСТАВЩИКИ» и подчиняете ему реальных контрагентов, система может начать воспринимать их как филиалы одной огромной компании. Это приведет к следующим последствиям:

Взаиморасчеты: При определенных настройках отчеты по дебиторской задолженности покажут общий долг на «папке» ПОСТАВЩИКИ, что неверно.
Оформление документов: Возможны ошибки при выборе партнера в документах, если система ожидает связь с конкретным контрагентом, а иерархия настроена как логические папки.
Ограниченность: Партнер может быть одновременно и поставщиком, и покупателем, но в иерархии элементов он может иметь только одного родителя.

Заключение

Подведем итог. Ошибка отбора «Реквизит не найден» лечится либо исправлением формирования пути к полю (использование Строка() вместо Наименование), либо переходом на использование штатных функций БСП для получения имен полей. Однако, прежде чем внедрять иерархические дополнительные реквизиты или создавать «папки» в справочнике Партнеры, мы рекомендуем проанализировать штатный механизм Сегментов. Это позволит избежать проблем с консолидацией данных и наследованием условий продаж, которые заложены в логику иерархии элементов 1С:Управление торговлей 11.4.