При выполнении крупных переходов между редакциями конфигураций (например, при обновлении «1С:Управление торговлей» с редакции 11.1 на 11.2 или 11.3) технические специалисты часто сталкиваются с двумя главными проблемами. На этапе сохранения конфигурации базы данных возникает критическая ошибка вида «Дублирование имени объекта метаданных» или «Имя предопределенного элемента не уникально». Если же этап Конфигуратора проходит, то при запуске в режиме «1С:Предприятие» процедура отложенного обновления информационной базы застревает на 100% или выполняющихся фоновых заданиях.
Рассмотрим подробно причины возникновения этих ошибок и разберем проверенные практические способы их решения.
Почему возникают ошибки дублирования объектов метаданных?
Проанализируем механику работы платформы «1С:Предприятие 8.3». Ошибки дублирования и неуникальности элементов возникают в следующих случаях:
Нарушение связи по идентификаторам (UUID): Если конфигурация ранее обновлялась через нештатное сравнение/объединение или загрузку сторонних файлов, внутренние идентификаторы метаданных вашей информационной базы могут перестать совпадать с GUID поставщика. В результате платформа пытается добавить существующий объект заново вместо его обновления.
Изменение структуры поставщиком: При переходе между крупными версиями (например, с 11.1 на 11.2) разработчики «1С» часто реорганизуют роли, подсистемы, функциональные опции или переименовывают реквизиты документов (например, Документ.ВводОстатков.ТабличнаяЧасть.РасчетыПоЭквайрингу.Реквизит.СуммаРегл). При несоблюдении порядка релизов старые и новые объекты начинают конфликтовать.
Дублирование предопределенных данных: Начиная с платформы 8.3.6, включен строгий контроль свойства ИмяПредопределенныхДанных. При наличии одинаковых имен предопределенных элементов в справочниках (например, в Справочник.ВидыКонтактнойИнформации) обновление блокируется.
Решение 1. Загрузка эталонной конфигурации (CF) текущего релиза
Разберем самый эффективный метод устранения повреждений метаданных перед совершением прыжка на новую редакцию. Этот способ помогает, если база была доработана или снята с поддержки некорректным образом.
Выполняем полную резервную копию информационной базы.
Скачиваем дистрибутив **полной установки** (не обновления) текущего релиза, на котором сейчас находится база (например, 11.1.10.199).
Заходим в Конфигуратор и выбираем пункт меню Конфигурация — Загрузить конфигурацию из файла..., указав файл 1C-Comp.cf от текущего чистого релиза.
Сохраняем конфигурацию базы данных (клавиша F7). Это действие «привязывает» все внутренние идентификаторы метаданных к правильным GUID поставщика и приводит конфигурацию к полностью типовому виду на замке.
После успешного обновления структуры метаданных повторяем попытку перехода на целевой релиз 11.2.2.119.
Решение 2. Уменьшение шага обновляемых релизов
Выясним, почему попытка обновляться через «большие прыжки» между версиями приводит к ошибкам. Файлы обновления .cfu содержат инструкции по изменению структуры данных от определенной версии. При пропуске промежуточных релизов платформа не всегда может корректно отработать удаление и переименование объектов.
Для успешного перехода выполним обновление по шагам с минимальным интервалом релизов:
Открываем матрицу порядков обновления конфигурации на портале ИТС.
Вместо прямого обновления с 11.1.10.199 на 11.2.2.119 выбираем цепочку промежуточных версий (например, через последние релизы веток 11.1.10 -> 11.2.1 -> 11.2.2).
После каждого шага обновлений в Конфигураторе обязательно запускаем режим «1С:Предприятие» и дожидаемся полного завершения обработчиков обновления информационной базы.
Решение 3. Что делать при зависании обновления на 100%
Рассмотрим ситуацию, когда Конфигуратор завершил работу без ошибок, но при запуске программы процесс обновления версии виснет, останавливаясь на обработчиках вроде ОбработкаНовостейУТ.ЗаполнитьОтборыНовостей или на регистрации данных в РИБ.
Причиной такого поведения являются фоновые и отложенные обработчики БСП. Фоновые службы новостей и интернет-поддержки пытаются обратиться к внешним серверам или пересчитать огромные массивы данных в регистрах.
Для исправления зависания применим следующий алгоритм:
Запуск со специальным ключом: При возникновении проблем с обновлением предопределенных данных в платформе, Конфигуратор можно запустить через командную строку с ключом отключения автоматической актуализации:
Отключение интеграционных служб: Временно заблокируем сетевой доступ или отключим регламентные задания загрузки новостей и интернет-поддержки в настройках программы перед обновлением.
Принудительный запуск отложенных обработчиков: Если процедура застряла в фоновом режиме, перейдем в раздел Администрирование — Обслуживание — Результаты обновления программы. Нажмем ссылку «Администрирование отложенного обновления» и запустим выполнение процедур вручную в монопольном режиме.
Решение 4. Альтернативный вариант (Перенос остатков в чистую базу)
Если конфигурация накапливала ошибки метаданных годами и штатные процедуры обновления не помогают, разберем радикальный, но гарантированный способ перехода на новую редакцию:
Разворачиваем абсолютно новую пустую информационную базу целевого релиза (например, УТ 11.2 или 11.3).
Используем стандартные обработки перенос данных или правила конвертации (КД) для переноса справочной информации и нормативно-справочной информации (НСИ).
Переносим начальные остатки на дату ввода и отказываемся от переноса накопленной «мусорной» истории документов. Это не только решит проблему с ошибками обновления, но и существенно ускорит работу базы данных.