Как определить первоначальное значение предопределенного справочника, если его переименовали

← На главную

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

Разберем ситуацию на примере: в справочнике СпособыОтраженияЗарплатыВРегламентированномУчете элемент, который изначально назывался "Отражение больничных за счет предприятия", теперь называется иначе. Как нам выяснить, какой именно элемент перед нами, и какова была его изначальная суть? Рассмотрим несколько эффективных способов решения этой задачи.

Разграничение понятий: Имя и Наименование

Прежде всего, проанализируем, как устроены предопределенные данные в платформе 1С. У любого такого элемента есть три важных идентификатора:

Имя (в Конфигураторе): Технический идентификатор (например, ОтражениеБольничныхЗаСчетРаботодателя). Он уникален и обычно не меняется. Именно к нему обращаются программисты через код: Справочники.СпособыОтражения.ИмяЭлемента.
Синоним: То, что разработчик планировал показывать пользователю изначально.
Наименование (в режиме Предприятия): Строковое поле, которое пользователь видит в списке и может редактировать. Именно его изменение и создает проблему.

Наша задача — "докопаться" до технического Имени, которое остается неизменным в метаданных.

Способ 1: Сравнение с конфигурацией поставщика

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

Рассмотрим пошагово, как это сделать:

Запустите Конфигуратор.
Перейдите в меню Конфигурация — Поддержка — Настройка поддержки.
Найдите в дереве нужный справочник (например, СпособыОтраженияЗарплатыВРегламентированномУчете).
Нажмите кнопку Сравнить/объединить (или просто откройте окно сравнения через "Конфигурация — Сравнить конфигурации", выбрав "Конфигурация поставщика" и "Основная конфигурация").
В окне сравнения найдите ветку Предопределенные данные. Система покажет разницу между тем, что в базе сейчас, и тем, что было заложено разработчиком типового решения.

Этот метод позволяет увидеть исходные значения даже в том случае, если в Конфигураторе были изменены сами метаданные предопределенных элементов.

Способ 2: Использование консоли запросов

Выясним причину переименования, не заходя в Конфигуратор глубоко. Для этого нам понадобится консоль запросов. В платформе 1С 8.2 и 8.3 у предопределенных элементов есть скрытое поле ИмяПредопределенныхДанных, которое хранит тот самый технический идентификатор из метаданных.

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


ВЫБРАТЬ
    Способы.Ссылка КАК Ссылка,
    Способы.Наименование КАК ТекущееНаименование,
    Способы.ИмяПредопределенныхДанных КАК СистемноеИмя
ИЗ
    Справочник.СпособыОтраженияЗарплатыВРегламентированномУчете КАК Способы
ГДЕ
    Способы.Предопределенный = ИСТИНА

Результат запроса выведет таблицу, где в колонке СистемноеИмя вы увидите "настоящее" название элемента, заложенное программистом (например, ОтражениеБольничныхЗаСчетРаботодателя), а в колонке ТекущееНаименование — то, что ввел пользователь (например, ПАО Газпром). Сразу станет ясно, какой элемент подвергся правке.

Способ 3: Программный метод получения имени

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

Рассмотрим программный код для получения информации:


// Предположим, ВыбранаяСсылка — это подозрительный элемент справочника
Если ВыбранаяСсылка.Предопределенный Тогда
    ИмяВМетаданных = ВыбранаяСсылка.Метаданные().Имя; // Имя самого справочника
    СистемноеИмяЭлемента = ВыбранаяСсылка.ИмяПредопределенныхДанных;
    
    Сообщить("Элемент в базе называется: " + ВыбранаяСсылка.Наименование);
    Сообщить("А в конфигураторе он: " + СистемноеИмяЭлемента);
Иначе
    Сообщить("Этот элемент не является предопределенным.");
КонецЕсли;

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

Способ 4: Анализ Журнала регистрации

Проанализируем ситуацию: если переименование произошло недавно, мы можем узнать не только старое название, но и кто именно совершил это действие. Журнал регистрации фиксирует старые и новые значения полей при записи объекта.

Откройте Журнал регистрации (Сервис — Журнал регистрации).
Установите отбор по объекту (выберите конкретную ссылку справочника).
Установите событие: Данные — Изменение.
Просмотрите детальные записи. В колонке "Данные" при двойном клике на строку изменения часто можно увидеть структуру XML с измененными реквизитами, где будет указано: Наименование: Было "..." Стало "...".

Способ 5: Выгрузка конфигурации в файлы (XML)

Если сравнение с конфигурацией поставщика невозможно (например, конфигурация полностью самописная и ЦФ-ника под рукой нет), мы можем исследовать структуру предопределенных данных через выгрузку в файлы.

Выполним следующие шаги:

В Конфигураторе выберите меню Конфигурация — Выгрузить конфигурацию в файлы...
Укажите пустую папку.
После выгрузки перейдите в папку и найдите подпапку Catalogs, а в ней — папку вашего справочника.
Откройте файл Ext/Predefined.xml.

В этом XML-файле будет четко прописана структура всех предопределенных элементов с их Name (Имя в конфигураторе) и Description (Наименование по умолчанию). Это "паспорт" справочника, который покажет, что планировал создать разработчик изначально.

Заключение

Мы разобрали пять способов идентификации переименованных предопределенных данных. Наиболее быстрым является запрос к полю ИмяПредопределенныхДанных, а наиболее информативным — сравнение с конфигурацией поставщика. Помните, что переименование предопределенных элементов в режиме Предприятия — плохая практика, так как это вводит в заблуждение как пользователей, так и специалистов по поддержке. Рекомендуется возвращать наименования к их исходному виду или фиксировать изменения в документации к системе.