← На главную

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

Выясним причину поведения платформы

Проанализируем механику работы Конфигуратора 1С. При любом переименовании реквизита, элемента формы или объекта метаданных платформа запускает встроенную проверку — механизм авторефакторинга. Система начинает сканировать тексты модулей, встроенные запросы, макеты и формы во всей конфигурации в поиске совпадений имени изменяемого реквизита.

Так как новый документ был создан методом копирования оригинала, имена всех его реквизитов на начальном этапе полностью совпадают с названиями реквизитов исходного объекта. В силу динамической типизации встроенного языка 1С платформа не всегда может со 100% точностью определить контекст — принадлежит ли конкретное имя реквизита в коде новому документу или исходному. Из-за этого Конфигуратор помечает все найденные совпадения как возможные места использования и предлагает автозамену по всей конфигурации.

Проанализируем риски применения автоматической замены

Если в окне результатов поиска согласиться с предложением платформы и применить автозамену для всех найденных ссылок, возникнут следующие проблемы:

1. Повреждение сторонних объектов: Имя реквизита изменится в модулях, запросах и формах исходного документа и других объектов, где встречалось аналогичное наименование.
2. Нарушение работоспособности системы: В исходных документах и связанных с ними бизнес-процессах возникнут критические ошибки при выполнении кода и запросов.
3. Избыточные изменения метаданных: Конфигурация зафиксирует правки в десятках объектов, которые разработчик вручную даже не открывал, что усложнит захват объектов в хранилище и последующую поддержку.

Разберем по шагам варианты решения проблемы

Рассмотрим несколько проверенных способов безопасной работы при переименовании реквизитов скопированных объектов.

Способ 1. Выборочное подтверждение изменений в окне поиска

Если вы хотите использовать авторефакторинг только для нового документа, выполните следующие шаги:

1. После изменения имени реквизита дождитесь появления диалогового окна с результатами поиска механизма рефакторинга.
2. Внимательно изучите дерево найденных объектов.
3. Установите флажки (галочки) исключительно для элементов, принадлежащих новому документу (его модулю объекта, модулям его форм и макетам).
4. Снимите флажки со всех сторонних документов, справочников, общих модулей и регистров.
5. Нажмите кнопку подтверждения замены.

Способ 2. Отключение автоматической проверки рефакторинга

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

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

Способ 3. Ручное переименование и поиск ссылок

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

Рассмотрим меры предосторожности и рекомендации

Чтобы обезопасить конфигурацию от нежелательных массовых изменений, соблюдайте следующие правила:

1. Резервное копирование: Перед переименованием реквизитов или масштабными изменениями метаданных всегда создавайте выгрузку информационной базы (файл .dt) или локальный бэкап.
2. Использование Хранилища конфигурации: При групповой разработке помещайте объекты в хранилище перед внесением изменений. В случае ошибочного массового рефакторинга вы всегда сможете отменить изменения и получить актуальную версию из хранилища.
3. Использование расширений: При доработке типовых решений создавайте новые объекты и реквизиты в расширениях конфигурации, чтобы не нарушать целостность основного типового решения.