Расширение 1С ссылается на объект, которого уже нет: ищем и лечим неразрешимые ссылки

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

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

Откуда берутся неразрешимые ссылки в расширениях

Расширение не хранит копию всей конфигурации. Оно хранит только свои объекты и «заимствованные» объекты основной конфигурации, которые вы перекрыли или дополнили. Связь идёт по именам и внутренним идентификаторам. Пока объект в основной конфигурации на месте, всё резолвится. Исчез объект — ссылка повисла.

Типичные сценарии:

• 🔄 Обновление типовой конфигурации. В новом релизе убрали реквизит, табличную часть, команду или форму, а в расширении они были заимствованы или использовались в запросе.
• ✏️ Переименование. Объект переименовали в основной конфигурации. Для платформы это новый объект, старая ссылка из расширения не находит адресата.
• 🧩 Удаление объекта из расширения. Вы удалили справочник или регистр, а в модулях, формах, ролях, подсистемах или макетах остались упоминания.
• 🔀 Перенос расширения между базами. Расширение подготовили для одной версии конфигурации, а загрузили в базу с другой, где части объектов нет.
• 👥 Работа нескольких разработчиков. Один убрал объект, другой не заметил, что на него опираются его формы и права.

Различайте два случая. Если объект исчез из основной конфигурации, а в расширении остался заимствованный «двойник», платформа отметит его как не найденный в основной конфигурации. Если объект исчез из самого расширения, а ссылка осталась в роли, подсистеме, форме или команде, это обычная неразрешимая ссылка внутри метаданных.

Как найти проблемные места: проверка конфигурации и журнал регистрации

Сначала нужно понять, где именно висит ссылка. Угадывать не нужно: у платформы есть для этого инструменты.

Проверка конфигурации в Конфигураторе

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

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

Проверка из командной строки

На сервере сборки или в скрипте удобнее запускать проверку без интерфейса. Конфигуратор принимает команду CheckConfig с ключами. Для нашей задачи важен -IncorrectReferences. Расширение добавляется ключом -Extension с именем, а -AllExtensions проверит все подключённые.

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F "D:\Bases\Test" /N "Админ" /P "пароль" /CheckConfig -IncorrectReferences -AllExtensions /Out "D:\check.log"

Номер платформы в пути подставьте свой. Результат попадёт в файл check.log, его удобно читать и сравнивать между запусками.

Журнал регистрации

Ошибки, которые проявились уже при работе, ищите в журнале: меню Конфигуратора Администрирование → Журнал регистрации. Фильтруйте по уровню «Ошибка» и по периоду, когда возникла проблема. Нужные записи обычно находятся рядом с событиями вида «Данные.Ошибка» и «Сеанс.Ошибка».

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

Три способа исправить неразрешимые ссылки через Конфигуратор

Идите от простого к радикальному. Не переходите к следующему, пока не убедились, что предыдущий не помог.

Способ 1. Точечная правка ссылки

Откройте в дереве расширения объект из сообщения и найдите упоминание:

• в модуле (формы, объекта, менеджера) исправьте обращение к реквизиту или удалённому методу;
• в форме уберите элемент, привязанный к исчезнувшему реквизиту, или привяжите его к новому;
• в роли снимите право на удалённый объект;
• в подсистеме уберите объект из состава;
• в запросе замените таблицу или поле на актуальные.

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

Способ 2. Удалить заимствованный объект

Когда ваш объект в расширении является заимствованным «двойником» исчезнувшего объекта основной конфигурации, правка ссылок не поможет: адресата просто нет. Тут два варианта:

1. Если доработка по этому объекту уже не нужна (типовая конфигурация теперь делает то же сама), удалите заимствованный объект из расширения.
2. Если доработка нужна, найдите, куда разработчики перенесли функциональность. Заимствуйте новый объект заново и перенесите в него свои изменения.

Перед удалением посмотрите, что на объект ссылается. Используйте команду «Найти ссылки на объект» из контекстного меню (в Конфигураторе она доступна для объектов метаданных). Иначе вы удалите заимствованный объект, а ссылки из других мест превратятся в новые неразрешимые.

Перед массовым удалением сохраните выгрузку расширения в файл. Это занимает минуту, а откатить удаление без копии нельзя.

Способ 3. Загрузить расширение, подходящее к версии

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

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

Пример разбора одной ошибки

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

Правильный порядок такой:

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

Если после первой правки число сообщений упало с двадцати до одиннадцати, это нормально: часть ошибок снимается каскадом, остальное добивается руками.

Лечение в пакетном режиме: как «пересчитать» расширение после правок

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

1. Исправьте найденные ссылки.
2. Сохраните расширение: Конфигурация → Расширения конфигурации, выбрать расширение и сохранить изменения.
3. Запустите проверку конфигурации ещё раз.
4. Обновите конфигурацию базы данных (клавиша F7 в Конфигураторе).

Если после этого ошибка остаётся, проверьте, нет ли в базе нескольких версий одного расширения и не подключено ли дублирующееся. Отключите лишнее и запустите проверку снова.

Обновление конфигурации базы данных и расширения: что учесть

Расширение живёт вместе с базой, и порядок действий при обновлении определяет, появятся ли неразрешимые ссылки.

Что важно в процессе обновления:

• 📋 Перед обновлением типовой конфигурации выгрузите расширение в файл.
• 🧪 Обновляйте сначала копию базы . Проверка конфигурации с расширениями на копии покажет, что сломалось.
• 🔧 Если для расширения критична структура данных, обновление конфигурации базы данных (F7) выполняйте при монопольном доступе: его требует именно изменение структуры хранения, а не любая работа в Конфигураторе.
• 🔁 После обновления платформа может пометить расширение как требующее внимания. Не игнорируйте это сообщение: именно здесь она сообщает, что часть объектов не нашла основу.

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

Как не плодить неразрешимые ссылки при разработке расширений

Чем меньше расширение зависит от внутренних деталей типовой конфигурации, тем реже оно ломается после релиза. Практика, которая действительно работает:

• 🎯 Заимствуйте только то, что меняете. Каждый лишний заимствованный объект — потенциальная точка отказа при смене релиза.
• 🧱 Выносите свою логику в собственные общие модули расширения. В заимствованный модуль добавляйте только вызов.
• 🏷️ Используйте префикс для своих объектов. Так сразу видно, где ваше, а где типовое, и проще искать ссылки.
• 🔍 Не обращайтесь к реквизитам по имени там, где есть интерфейсные точки. Типовые подсистемы дают процедуры и события для расширения без прямых зависимостей.
• 📌 Фиксируйте, на какой релиз рассчитано расширение. Запишите в описании расширения номер версии конфигурации.
• 🧪 Включите проверку в процесс. Командная строка из раздела выше хорошо ложится в скрипт, который запускается после каждой загрузки релиза.

Частые вопросы