Часто при разработке или доработке конфигураций, таких как 1С:Документооборот, мы сталкиваемся с ситуацией, когда у справочника отключена нумерация. В таких случаях стандартный метод НайтиПоКоду() становится недоступным, а использование НайтиПоНаименованию() крайне нежелательно, так как пользователи могут в любой момент переименовать элемент, что приведет к поломке бизнес-логики.
Давайте вместе разберем эту проблему и рассмотрим самые надежные архитектурные решения, которые применяются в 1С-разработке для поиска и жесткой привязки к конкретным элементам справочника.
Если в коде необходимо закладывать разную логику в зависимости от конкретного элемента справочника, проанализируем самый правильный архитектурный подход. Лучшим решением будет сделать такие элементы предопределенными прямо в конфигураторе.
Платформа 1С:Предприятие 8.3 позволяет гибко управлять предопределенными элементами. Их можно привязывать и отвязывать от реальных данных базы в режиме предприятия. Если мы используем предопределенные данные, нам больше не нужен поиск как таковой. В коде мы просто обращаемся к элементу напрямую:
Справочники.ИмяСправочника.ИмяПредопределенногоЭлемента
Это самый надежный способ, который полностью исключает ошибки, связанные с поиском, переименованием или дублированием данных пользователями.
Поскольку задача часто связана с анализом "дополнительных свойств" документа, посмотрим на штатные механизмы современных конфигураций. Вместо изобретения собственных регистров сведений, разработчикам рекомендуется использовать встроенную подсистему БСП "Дополнительные реквизиты и сведения".
Для хранения свойств используется План видов характеристик ДополнительныеРеквизитыИСведения. БСП предоставляет готовый программный интерфейс для поиска и получения значений. Например, мы можем использовать экспортные функции общего модуля УправлениеСвойствами, такие как методы ЗначениеСвойства или ЗначенияСвойств. Это позволяет писать безопасный и обновляемый код в рамках стандартов 1С.
Рассмотрим классический паттерн для нетиповых справочников. Мы можем создать у справочника отдельный строковый реквизит, например ИдентификаторРазработчика, который будет недоступен для редактирования обычным пользователям. Этот реквизит заполняется программно или системным администратором при настройке.
Поиск в таком случае осуществляется стандартным платформенным методом:
Справочники.ИмяСправочника.НайтиПоРеквизиту("ИдентификаторРазработчика", "СпецСвойство1")
Преимущества этого подхода очевидны: код остается легко читаемым, а бизнес-логика защищена от пользовательских изменений наименования.
Если элементы справочника нужны для глобальной настройки системы, разберем подход с отдельными структурами хранения данных.
Константы.ИмяКонстанты.Получить().ХранилищеОбщихНастроек, сохраняя соответствия ссылок программно.Очень часто на форумах можно встретить советы искать элементы по их уникальному идентификатору (УИД). Разберем пример программной генерации и получения ссылки по УИД, предложенный в обсуждении:
Процедура СсылкуВТекстНаСервере(ЛюбаяСсылка)
тт = XMLСтрока(ЛюбаяСсылка);
пТип = ОбщегоНазначения.СтроковоеПредставлениеТипа(ТипЗнч(ЛюбаяСсылка));
пСтр = СтрШаблон("XMLЗначение(Тип(""%1""), ""%2"");", пТип, тт);
Сообщить(пСтр);
КонецПроцедуры
С помощью такой процедуры разработчики генерируют строку для вставки в рабочий код, получая конструкцию вида:
Возврат XMLЗначение(Тип("СправочникСсылка.ДополнительныеОтчетыИОбработки"), "f746588c-228b-11ec-96f4-3cecef453c5d");
Важное предупреждение: выясним причины, по которым такой подход считается антипаттерном "магические строки" и плохой практикой в 1С:
Поиск по УИД оправдан исключительно для задач обмена, синхронизации данных между разными системами (например, через регистр "Соответствия объектов информационных баз"), но его категорически не рекомендуется использовать для ветвления внутренней бизнес-логики конфигурации.