← На главную

Переход с редакции 2.0 конфигурации 1С:Бухгалтерия предприятия (обычные формы) на редакцию 3.0 (управляемые формы) — одна из наиболее ответственных задач при сопровождении информационных систем. Если база данных находится на полной поддержке («на замке»), обновление обычно проходит в штатном режиме. Однако если конфигурация находится в режиме «Редактируется с сохранением поддержки», разработчики регулярно сталкиваются с блокирующими ошибками объединения метаданных.

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

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

Для понимания сути проблемы проанализируем архитектурные различия между редакциями:

1. Смена архитектуры интерфейса: В редакции 2.0 командный интерфейс строился на объектах метаданных ветки Интерфейсы (например, Бухгалтерский, Полный, Административный). В их состав жестко прописывались ссылки на обычные формы документов, справочников, отчетов и обработок. В редакции 3.0 обычные формы полностью исключены из поставки, интерфейсы объявлены устаревшими, а навигация переведена на подсистемы и управляемый интерфейс «Такси».
2. Особенности механизма поддержки: Если для конфигурации включена возможность редактирования, платформа считает даже те типовые объекты, в которые не вносились правки, потенциально кастомизированными. При обновлении типовой файл поставщика пытается удалить старые обычные формы, но платформа не может завершить операцию, так как в объектах основной конфигурации (Интерфейс.Бухгалтерский и Интерфейс.Полный) на них все еще присутствуют жесткие ссылки. Возникает нарушение ссылочной целостности метаданных.
3. Некорректный выбор инструмента обновления: Часто ошибку усугубляет попытка выполнить переход через меню Конфигурация — Сравнить, объединить с конфигурацией из файла. Этот инструмент не предназначен для сквозного обновления версий: он не сопоставляет внутренние идентификаторы (UUID) удаляемых и замещаемых объектов поставщика, что гарантированно приводит к задвоению справочников, документов и регистров.

Способ 1. Полное удаление устаревших интерфейсов (Быстрое решение)

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

1. Создадим полную резервную копию информационной базы (выгрузку базы данных в файл .dt или копию на уровне СУБД).
2. Откроем дерево метаданных конфигурации базы данных и развернем ветку Общие — Интерфейсы.
3. Найдем интерфейсы, фигурирующие в сообщениях об ошибках: как правило, это Бухгалтерский и Полный (а также любые другие пользовательские интерфейсы, созданные на этапе эксплуатации редакции 2.0).
4. Выделим указанные интерфейсы и удалим их нажатием клавиши Delete. Если они включены в состав ролей, подтвердим удаление связей.
5. Нажмем клавишу F7 (или выберем меню Конфигурация — Обновить конфигурацию базы данных) и применим изменения структуры.
6. Повторим процедуру обновления на переходный релиз редакции 3.0 через штатный механизм поддержки. Все формы и устаревшие объекты удалятся без конфликтов ссылочной целостности.

Способ 2. Восстановление типового состояния интерфейсов через поддержку

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

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

Способ 3. Комплексная подготовка конфигурации и изоляция доработок

Если в базе редакции 2.0 редактировалось всего несколько объектов (как часто бывает, 2–3 реквизита или печатные формы), наиболее надежный путь — полностью вернуть типовые объекты на замок, оставив редактируемыми только реальные доработки.

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

Технологические требования при переходе на редакцию 3.0

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

1. Последовательность переходных релизов: Нельзя обновлять редакцию 2.0 сразу на последний актуальный релиз 3.0. Фирма «1С» выпускает специализированные переходные дистрибутивы (например, обновление с конкретного релиза 2.0.66.XX на специальный релиз 3.0.XX.XX). Только после успешного обновления на переходную версию и первого запуска в режиме предприятия выполняется дальнейшее последовательное обновление до актуального релиза.
2. Специальная роль для первого запуска: Перед первым входом в базу в режиме «1С:Предприятие» после наката редакции 3.0 учетной записи администратора необходимо обязательно назначить роль Администратор системы (для перехода на ред. 3.0). Без этой роли регламентные и фоновые процедуры первоначальной конвертации данных не запустятся, что приведет к повреждению учетных регистров.
3. Контроль нумерации документов: При переходе на управляемые формы меняется алгоритм формирования префиксов узлов и организаций, а также длина номеров некоторых документов. После завершения обновления обязательно проанализируем и протестируем создание новых документов каждого вида для исключения сбоев автонумерации.

Альтернативный вариант: переход через перенос данных

Если конфигурация редакции 2.0 содержит большое количество устаревших нетиповых механизмов, перенос которых на управляемые формы не планируется, сквозное обновление конфигурации накатом может оказаться нецелесообразным. В такой ситуации предпочтительнее развернуть чистую типовую конфигурацию 1С:Бухгалтерия предприятия 3.0 и выполнить перенос справочников и входящих остатков на начало расчетного периода с помощью типовых правил конвертации данных. Все необходимые доработки в дальнейшем реализуются с помощью механизма расширений конфигурации (.cfe), что оставляет основную базу полностью на типовой поддержке.