← На главную

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

Симптомы и суть проблемы

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

1. Даже если вы создадите совершенно новое, пустое расширение и добавите в него любой типовой объект (например, обработку АвтоматическоеИзвлечениеТекстов или объект языка Язык.Русский), сразу же появится ошибка неразрешимой ссылки.
2. Проблема не зависит от значения чекбокса «контролировать свойство».
3. Ошибки чаще всего возникают после перехода с веток 8.3.13–8.3.14 на релизы 8.3.15 (например, 8.3.15.1656 или 8.3.15.1830) и выше.

Разберем причины возникновения ошибки

Выясним причину такого поведения. Анализ показывает, что проблема носит комплексный характер и связана с архитектурными изменениями в новых версиях платформы:

1. Внутренние баги релизов 8.3.15: В этих версиях платформа иногда некорректно связывает внутренние идентификаторы (GUID) основной конфигурации и расширения. Появился флажок «Устанавливать соответствие объектов по внутренним идентификаторам», логика которого в переходных релизах отрабатывает со сбоями.
2. Нововведения и жесткий контроль: Начиная с 8.3.15, платформа стала гораздо строже контролировать любые изменения, особенно с появлением аннотации &ИзменениеИКонтроль. Если в основной конфигурации изменился тип, был удален или переименован реквизит, связанный с расширением (даже скрытый стиль или картинка), платформа может выдать ошибку на весь объект целиком.
3. Нарушение связей при обновлении: Использование стандартного сравнения/объединения для расширений при обновлении типовой конфигурации часто «ломает» внутренние ссылки.
4. Сбои кэша и базы данных (SDBL): Иногда проблема сопровождается скрытыми ошибками на уровне таблиц базы данных.

Способы решения: разберем по шагам

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

1. Использование метода «Загрузка конфигурации из файла»

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

1. Выгрузите ваше исправленное расширение в файл .cfe.
2. В рабочей базе откройте список расширений.
3. Вместо «Обновить из файла...» (которое под капотом делает объединение), используйте команду «Загрузка конфигурации из файла».
4. Этот метод заставит платформу полностью перезаписать структуру расширения и восстановить разорванные связи идентификаторов с основной конфигурацией.

2. Выгрузка расширения в исходники (XML)

Проанализируем ситуацию, когда GUID объектов окончательно «разъехались». В этом случае помогает пересборка расширения через XML:

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

3. Глубокая очистка кэша и тестирование базы (ТиИ)

Если ошибка сопровождается сообщениями SDBL, выполним сервисное обслуживание:

1. Полностью очистите сеансовые данные и кэш (как клиентский на рабочих местах, так и серверный кэш кластера серверов 1С).
2. Запустите процедуру Тестирование и исправление в Конфигураторе.
3. Обязательно отметьте пункты «Проверка логической целостности» и «Проверка ссылочной целостности».

4. Откат на стабильную версию платформы (Даунгрейд)

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

Многие типовые конфигурации (например, Бухгалтерия 3.0.75), хоть и требуют по документации ветку 8.3.15, фактически стабильно работают и ставятся на 8.3.14. Возврат на эту версию позволяет переждать нестабильность релизов 8.3.15, пока вы не будете готовы к переходу на более новые, исправленные ветки (например, 8.3.17 или выше), где работа с внутренними идентификаторами расширений была окончательно стабилизирована.

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