В процессе работы с современными конфигурациями на платформе 1С:Предприятие 8.3 (такими как ERP, Управление торговлей 11 или Комплексная автоматизация) программисты и администраторы часто сталкиваются с аномальным поведением механизма «Ввод по строке». Проблема проявляется следующим образом: пользователь начинает вводить наименование или код в поле выбора, и в выпадающем списке рядом с привычными данными появляются странные наборы цифр, не соответствующие официальному коду записи. Например, вместо кода 00-00000202 система может выводить число 8153571.
Особенно часто эта ситуация возникает после обновления версии конфигурации или платформы. В данной статье мы подробно разберем, почему стандартные средства индексации могут не помогать, и где именно в «потрохах» системы скрывается истинная причина такого поведения.
Для начала проанализируем, как 1С формирует список подсказок при вводе текста в поле. В простых конфигурациях за это отвечают настройки метаданных: свойства справочника Способ поиска при вводе по строке и список полей в Ввод по строке. Однако в современных типовых решениях этот процесс давно перестал быть чисто платформенным.
Рассмотрим ситуацию, когда стандартных настроек недостаточно. Система использует программное переопределение поиска. Нам необходимо обратиться к Модулю менеджера соответствующего объекта (например, справочника Партнеры).
Выясним причину, по которой платформа может игнорировать настройки метаданных. В модуле менеджера существует предопределенная процедура ОбработкаПолученияДанныхВыбора. Именно здесь разработчики фирмы «1С» часто описывают сложную логику поиска, которая учитывает дополнительные фильтры, права доступа или иерархию.
Проанализируем примерную структуру этой процедуры:
Процедура ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
// Если СтандартнаяОбработка установлена в Ложь,
// 1С не использует настройки из метаданных (Ввод по строке)
СтандартнаяОбработка = Ложь;
// Здесь формируется запрос, который может собирать представление
// из разных реквизитов, включая скрытые идентификаторы
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ
| Партнеры.Ссылка КАК Ссылка,
| Партнеры.Наименование + "" ("" + Партнеры.КодДебетПлюс + "")"" КАК Представление
|ИЗ
| Справочник.Партнеры КАК Партнеры
|ГДЕ
| Партнеры.Наименование ПОДОБНО &ТекстЗапроса";
// ... дальнейшая логика заполнения ДанныеВыбора
КонецПроцедуры
Если после обновления конфигурации логика в этой процедуре была изменена, она может принудительно добавлять к представлению внутренние идентификаторы или коды из других учетных систем (например, КодДебетПлюс, как в рассматриваемом нами случае). Если вы видите «непонятные цифры», первым делом проверьте, не формируются ли они программно в этом месте.
Иногда очистка индексов через стандартное меню «Управление полнотекстовым поиском» в пользовательском режиме не дает результата. Рассмотрим ситуацию глубже. Полнотекстовый поиск может хранить «мусорные» данные, которые подмешиваются в выдачу. Проанализируем процесс глубокой очистки индекса:
1C:Enterprise Server Administration (для клиент-серверного варианта) или закроем базу (для файлового).IndexFullTextSearch.Странные числа (например, 8153571) могут быть внутренними ID строк в таблицах SQL или файловой базы, которые индексатор ошибочно распознал как текстовые данные из-за сбоя структуры таблиц после обновления.
Посмотрим на ситуацию со стороны расширений. В современной разработке на 1С расширения используются повсеместно. Если расширение перехватывает ту же процедуру ОбработкаПолученияДанныхВыбора с аннотацией &Вместо или &После, оно может модифицировать результат поиска. Выясним, нет ли в базе активных расширений, которые пытаются «улучшить» поиск по справочнику Партнеры. Часто разработчики забывают адаптировать расширения под новый релиз основной конфигурации, что и приводит к визуальным глюкам.
Рассмотрим еще одну коварную причину — кэш. У платформы 1С есть механизм кэширования представлений. Если объект был изменен, в локальном кэше пользователя может сохраниться старая связка «Ссылка — Текст представления». Проанализируем, как эффективно почистить кэш, помимо простого удаления базы из списка запуска:
Необходимо очистить содержимое папок ConfigSave и Sccache, расположенных в профиле пользователя в каталоге %AppData%\1C\1cv8\. Именно там могут оседать некорректные метаданные о структуре поиска, подтянутые сразу после обновления.
Проанализируем настройки реквизитов. Если мы включаем в Ввод по строке несколько полей (например, Наименование, Код, КодДебетПлюс), 1С формирует сложный запрос к базе данных. Если один из этих реквизитов имеет тип, отличный от строки, или сложную индексацию, платформа может попытаться привести его к строковому виду. В ряде случаев (особенно в версиях платформы 8.3.15–8.3.18) наблюдался баг, когда вместо значения реквизита в строку поиска подставлялся внутренний GUID записи или его десятичное представление.
Посмотрим на пример: число 8153571 может оказаться частью ИНН, внутренним номером записи в регистре сведений СоответствияОбъектовИнформационныхБаз или даже ссылочным номером из другой системы, с которой настроен обмен (синхронизация данных).
В конфигурациях УТ 11 / ERP справочник Партнеры является управленческим, а Контрагенты — юридическим. Зачастую поиск настроен так, что при поиске партнера система автоматически ищет и по данным связанного контрагента. Выясним, не является ли «странное число» ИНН или КПП связанного юридического лица. Если в настройках поиска включен поиск по всем полям, система будет выводить любые совпадения, которые найдет в связанных таблицах.
Чтобы окончательно решить проблему, выполним следующие шаги:
ОбработкаПолученияДанныхВыбора. Если она есть, проанализируем, какой запрос там выполняется. Попробуем временно закомментировать СтандартнаяОбработка = Ложь; и проверить, исчезнет ли проблема.Код, попробуем оставить только Наименование и проверить результат. Это поможет понять, является ли проблема системной или относится к конкретному полю.Подводя итог, можно сказать, что появление непонятных кодов при поиске — это почти всегда признак того, что программный код или поврежденный индекс переопределяют стандартное поведение платформы. Внимательный аудит модуля менеджера и полная физическая очистка папок индекса обычно позволяют решить эту задачу.