← На главную

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

Особенности платформы и сохранность данных в СУБД

Прежде чем приступать к масштабным правкам, важно понять, как платформа 1С:Предприятие взаимодействует с базой данных. Связь объектов конфигурации с физическими таблицами СУБД осуществляется не по строковому имени, а по внутренним уникальным идентификаторам (UUID). Физические таблицы в базе имеют системные имена вида _ReferenceX или _DocumentX. Поэтому само по себе переименование существующего объекта в дереве метаданных не приводит к удалению или пересозданию физической таблицы и не стирает существующие данные в СУБД.

Важно: потеря данных возможна в том случае, если разработчик удалит старый объект и создаст новый с тем же типом, либо некорректно выполнит объединение конфигураций (когда переименованный объект распознается как абсолютно новый). При реструктуризации старая таблица с данными будет удалена.

Способ 1. Использование встроенного механизма глобального поиска и замены

Классический подход в стандартном конфигураторе заключается в последовательной замене имени во всей конфигурации. Разберем этот алгоритм по шагам:

1. Переименуем сам объект в дереве метаданных (например, справочник СтароеИмя в НовоеИмя).
2. Откроем пункт меню Правка — Глобальная замена (или комбинация клавиш Ctrl + Shift + F2).
3. В поле поиска укажем старое наименование объекта, а в поле замены — новое.
4. Зададим область поиска: вся конфигурация, включая модули объектов, менеджеров, форм, общие модули и описания метаданных.
5. Выполним замену и проверим измененные фрагменты кода.

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

Способ 2. Семантический рефакторинг в 1C:EDT

Среда разработки 1C:Enterprise Development Tools (1C:EDT) на базе Eclipse содержит развитый механизм контекстного рефакторинга. В отличие от обычной текстовой замены в конфигураторе, EDT понимает структуру и семантику метаданных.

При переименовании объекта через EDT среда автоматически обновляет:

1. Ссылки на объект в коде на встроенном языке.
2. Тексты запросов с обращением к таблицам объекта.
3. Типы реквизитов других объектов, ссылающихся на переименованный элемент.
4. Источники в подписках на события.
5. Составы функциональных опций и планов обмена.
6. Пути к данным и реквизиты управляемых форм.

Этот способ является наиболее быстрым и минимизирует вероятность человеческой ошибки при переименовании крупных объектов.

Способ 3. Выгрузка конфигурации в XML или файлы и пакетная обработка

Для опытных разработчиков доступен вариант с пакетной обработкой исходников конфигурации:

1. Выгрузим конфигурацию в файлы (через механизм Конфигурация — Выгрузить конфигурацию в файлы или выгрузку в XML).
2. С помощью внешних текстовых редакторов с поддержкой регулярных выражений выполним точечную замену вхождений старого имени.
3. Загрузим измененные исходные файлы обратно в базу.
4. Обязательно выполним полную синтаксическую проверку и проверку логической целостности конфигурации.

Скрытые точки отказа: на что обратить внимание

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

1. Динамические обращения по строковым именам: конструкции получения менеджеров через коллекции (Справочники[Имя]), функции работы с типами вида Тип("СправочникСсылка.СтароеИмя"), а также обращения через Метаданные.НайтиПоПолномуИмени() не определяются стандартной проверкой синтаксиса.
2. Подписки на события: необходимо вручную убедиться, что типы источников в подписках на события корректно обновились и не содержат пустых ссылок.
3. Ограничения доступа (RLS): в текстах условий и шаблонов ограничения прав доступа часто содержатся жестко прописанные имена таблиц.
4. Внешние отчеты и обработки: внешние файлы используют жесткую привязку к именам метаданных. После переименования объекта все связанные внешние инструменты перестанут работать до их ручной корректировки.
5. Интеграции и обмен данными: правила обмена (Конвертация данных 2.0 / 3.0, формат EnterpriseData), HTTP- и Web-сервисы, а также внешние базы данных, подключающиеся через COM или REST API, перестанут находить переименованный объект.
6. Хранилища пользовательских настроек: варианты отчетов и пользовательские отборы динамических списков, сохраненные в базе, содержат сериализованные имена типов. При изменении имени метаданных старые пользовательские настройки могут сброситься.

Альтернативный вариант: изменение синонима

Если цель переименования — сделать название понятным для конечных пользователей, в большинстве случаев правильнее изменить только Синоним объекта в палитре свойств.

Посмотрим на преимущества изменения синонима:

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

Если же старое имя объекта грубо нарушает стандарты разработки и принято решение о полном переименовании, необходимо последовательно выполнить рефакторинг (через 1C:EDT или глобальную замену), проверить все динамические вызовы, обновить внешние компоненты и провести полное функциональное тестирование конфигурации.