← На главную

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

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

Анализ проблемы: почему сравнение и объединение работает некорректно

Проанализируем механику работы платформы «1С:Предприятие» при разных сценариях обновления:

1. Обновление через поддержку (меню Конфигурация – Поддержка – Обновить конфигурацию). Этот штатный механизм использует файлы обновления поставки (.cfu или .cf) и специальные таблицы соответствий. Платформа сопоставляет метаданные по их внутренним идентификаторам (UUID). Благодаря этому старый справочник ЗначенияСвойствОбъектов корректно сопоставляется с объектом УдалитьЗначенияСвойствОбъектов, а новый справочник создается с нуля без повреждения существующих ссылок.
2. Сравнение и объединение с файлом (меню Конфигурация – Сравнить, объединить с конфигурацией из файла). Этот инструмент предназначен для переноса конкретных изменений между одинаковыми структурами и всегда сопоставляет объекты первого уровня исключительно по строковым именам. В результате старый справочник со всеми историческими ссылками и типами владельцев сопоставляется с новым одноименным справочником. При попытке применить такие изменения реструктуризация завершается ошибкой (например, из-за невозможности сменить тип владельца или родителя у существующих данных).

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

Способ 1. Создание эталонного CF и полная загрузка конфигурации

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

1. Подготовка чистой базы: берем копию типовой базы исходной редакции (например, 1.2) без доработок.
2. Штатное обновление: выполняем стандартное обновление через поддержку файлом поставки новой редакции (2.0).
3. Первый запуск предприятия: обязательно запускаем обновленную базу в режиме «1С:Предприятие» под администратором и дожидаемся завершения работы обработчиков обновления Библиотеки стандартных подсистем (БСП). Это необходимо для корректной инициализации служебных регистров, профилей групп доступа и миграции данных.
4. Перенос доработок: открываем конфигуратор обновленной эталонной базы и переносим необходимые доработки, адаптированные под новую редакцию и управляемые формы.
5. Сохранение эталона: выгружаем готовую конфигурацию в файл (Конфигурация – Сохранить конфигурацию в файл...). В полученном файле .cf будет сохранена правильная цепочка UUID и актуальная конфигурация поставщика.
6. Применение на рабочих базах: на целевой информационной базе выполняем предварительное создание резервной копии и применяем переход через меню Конфигурация – Загрузить конфигурацию из файла.... Данная операция полностью заменяет основную конфигурацию и конфигурацию поставщика, предотвращая коллизии сопоставления по именам.
7. Финальный запуск: запускаем рабочую базу в пользовательском режиме с параметром /ЗапуститьОбновлениеИнформационнойБазы для выполнения регламентных процедур БСП.

Способ 2. Двухэтапное обновление через поддержку с последующим переносом доработок

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

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

Способ 3. Ручная корректировка соответствий в окне сравнения и объединения

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

Рассмотрим, как выявить и переназначить сопоставление:

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

Способ 4. Создание собственной конфигурации поставщика для тиражирования

Для регулярного тиражирования обновлений клиентам лучшим подходом является оформление собственной поставки:

1. Переводим доработанную конфигурацию на режим поставки собственной конфигурации разработчика (формируется собственный файл поставки .cfu).
2. Клиенты получают файл .cfu и обновляют базу через стандартный механизм поддержки без ручного выбора галочек в сравнении/объединении.
3. Такой способ гарантирует корректное сопоставление по внутренним идентификаторам и сохраняет правила поддержки в клиентских базах.