При работе с современными конфигурациями на базе 1С:Предприятие 8.3, такими как Управление торговлей 11.4 или ERP Управление предприятием 2.5, специалисты часто сталкиваются с механизмом дополнительных реквизитов и сведений. Этот инструмент крайне удобен, так как позволяет расширять состав данных объектов без внесения изменений в конфигурацию. Однако иногда стандартные механизмы дают сбой. Типичная ситуация: вы создаете общий дополнительный реквизит для справочника Партнеры, выводите его в список, пытаетесь установить фильтр, и система выдает критическую ошибку: «Поле реквизита не найдено». В этой статье мы подробно разберем, почему это происходит и как решить проблему с помощью программных средств и настроек.
Для начала проанализируем ситуацию с технической точки зрения. В 1С дополнительные реквизиты хранятся в табличных частях (обычно это ТЧ ДополнительныеРеквизиты). Однако в динамических списках (формах списков справочников или документов) система для оптимизации пытается обращаться к этим данным не через классический запрос к табличной части, а через механизм виртуальных полей, предоставляемый Библиотекой стандартных подсистем (БСП).
Проблема кроется в поле НаборСвойств у элемента плана видов характеристик ДополнительныеРеквизитыИСведения. Когда мы создаем «общий» реквизит, система автоматически привязывает его к определенному набору. Если при построении динамического списка алгоритм БСП обнаруживает, что реквизит жестко связан с набором, который не полностью соответствует контексту текущего списка (например, в списке партнеров отображаются объекты разных типов), запрос к базе данных формируется некорректно. Система ожидает найти поле по одному имени, а в метаданных списка оно зарегистрировано иначе. В итоге мы получаем сообщение о том, что поле не найдено, хотя визуально оно присутствует в настройках формы.
Наиболее эффективным способом решения, подтвержденным практикой многих разработчиков, является программная очистка реквизита НаборСвойств у проблемного дополнительного реквизита. Это делает реквизит «по-настоящему общим» для системы, заставляя механизмы БСП обращаться к нему по уникальному идентификатору (GUID) напрямую, минуя привязку к конкретным группам свойств.
Рассмотрим по шагам, как это реализовать. Нам необходимо создать внешнюю обработку или воспользоваться консолью кода, чтобы выполнить следующий алгоритм:
ДополнительныеРеквизитыИСведения.НаборСвойств в состояние ПустаяСсылка.ОбменДанными.Загрузка = Истина, чтобы обойти стандартные проверки при записи (это критически важно, так как штатные формы не позволят записать реквизит без набора).Посмотрим на пример кода, который решает эту задачу:
// Предположим, что СсылкаНаРеквизит — это ссылка на наш доп. реквизит
ОбъектРеквизита = СсылкаНаРеквизит.ПолучитьОбъект();
// Очищаем привязку к конкретному набору свойств
ОбъектРеквизита.НаборСвойств = Справочники.НаборыДополнительныхРеквизитовИСведений.ПустаяСсылка;
// Устанавливаем режим загрузки для пропуска проверок заполнения
ОбъектРеквизита.ОбменДанными.Загрузка = Истина;
// Фиксируем изменения в базе данных
ОбъектРеквизита.Записать();
После выполнения этого кода механизм компоновки данных в динамическом списке начнет корректно определять поле, и фильтрация заработает без ошибок.
Проанализируем ситуацию, почему ошибка чаще всего проявляется именно в справочнике Партнеры. В УТ 11.4 этот справочник имеет сложную структуру наборов свойств. Партнер может быть одновременно и клиентом, и поставщиком, или просто «прочим» контрагентом. Для каждой из этих ролей предусмотрены свои наборы дополнительных реквизитов. Когда вы добавляете общий реквизит, система пытается «угадать», к какому набору его отнести. Если у конкретной записи в базе данных поле НаборСвойств не проинициализировано или конфликтует с общим набором справочника, динамический список ломается.
Интересно, что для справочника Номенклатура такие проблемы встречаются реже, так как там иерархия наборов более линейна и обычно привязана к видам номенклатуры. Тем не менее, описанный выше метод с очисткой ссылки является универсальным средством для любого типа объектов.
Иногда проблема может носить временный характер и быть связанной с кэшированием метаданных динамического списка на стороне клиента или сервера. Прежде чем приступать к программной правке реквизитов, проанализируем и попробуем более простые действия, которые также помогают в ряде случаев:
Важно понимать: после того как вы программно очистите НаборСвойств, данный реквизит может перестать отображаться в стандартном окне «Редактирование дополнительных реквизитов» через пользовательский интерфейс. Поскольку система больше не знает, к какой группе его относить, она может «спрятать» его из списка настройки.
Если вам потребуется в будущем изменить настройки этого реквизита (например, поменять его наименование или тип значения), вам придется либо временно вернуть НаборСвойств программно, либо воспользоваться обработкой «Групповое изменение реквизитов». Однако, как показывает практика, для стабильной работы фильтров в крупных базах этот компромисс является оправданным.
Таким образом, мы выяснили, что ошибка «Поле не найдено» — это следствие избыточной жесткой связи метаданных БСП и структуры динамического списка. Используя предложенный код для очистки набора свойств, вы сможете обеспечить стабильную работу фильтров для ваших пользователей.