← На главную

Переход с редакции 2.0 на 3.0 в «1С:Бухгалтерия предприятия» — это не просто очередное обновление, а полноценная смена архитектуры приложения. Часто системные администраторы и программисты сталкиваются с ситуацией, когда текущий релиз 2.0 (например, 2.0.67.23) оказывается «слишком свежим» для имеющегося дистрибутива обновления 3.0, который рассчитан на версию 2.0.67.22. В этой статье мы подробно разберем, как действовать в такой ситуации, какие инструменты использовать и как подготовить базу к корректной конвертации данных.

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

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

Вариант 1: Ожидание подходящего релиза (наиболее безопасный путь)

Если разница в номерах релизов минорная (как в случае с 2.0.67.22 и 2.0.67.23), самым простым и надежным способом будет дождаться выхода следующей версии БП 3.0. Обычно поддержка новых минорных релизов 2.0 добавляется в 3.0 в течение 1–3 недель. Рассмотрим преимущества этого метода:

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

Вариант 2: Откат на предыдущую копию с переносом данных

Если обновление на 3.0 требуется незамедлительно, мы можем рассмотреть вариант возврата к состоянию базы, когда она еще имела «правильный» номер релиза (в нашем примере — 2.0.67.22). Разберем этот процесс по шагам:

1. Восстановление копии: развернем резервную копию базы, сделанную до последнего обновления 2.0.
2. Выгрузка изменений: из текущей рабочей базы (релиз .23) необходимо выгрузить все документы и элементы справочников, созданные или измененные с момента создания копии.
3. Использование универсального обмена: для переноса данных используем обработку УниверсальныйОбменДаннымиXML. Так как структуры баз практически идентичны, стандартные правила обмена справятся с задачей на 100%.
4. Синхронизация идентификаторов: при переносе важно убедиться, что поиск объектов идет по УникальныйИдентификатор (GUID), чтобы не возникло дублей.

После того как данные в копии с релизом .22 будут актуализированы, можно запускать стандартную процедуру перехода на 3.0.

Вариант 3: Использование «Конвертации данных»

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

Техническая подготовка базы перед переходом

Независимо от выбранного способа, переход на 3.0 требует тщательной подготовки. Пропустив эти шаги, мы рискуем получить некорректные остатки или «битые» ссылки.

1. Тестирование и исправление (ТиИ)

Перед запуском обновления обязательно выполним ТиИ в конфигураторе. Нам важны следующие пункты:

• Реиндексация таблиц информационной базы.
• Проверка логической целостности.
• Проверка ссылочной целостности (обязательно выбрать «Очищать объекты» или «Создавать объекты» для битых ссылок).

2. Платформа и системные требования

Выясним требования новой версии: БП 3.0 работает только на платформе 8.3 в режиме управляемого приложения. Проверьте, чтобы версия платформы была не ниже рекомендуемой в файле readme.txt к дистрибутиву. Также помните, что интерфейс «Такси» требует больше оперативной памяти (рекомендуется от 8 ГБ на рабочее место пользователя).

3. Удаление помеченных объектов

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

Процесс обновления и отложенные обработчики

Посмотрим, что происходит после того, как мы накатили .cfu файл и запустили базу в режиме «Предприятие». Появится окно обновления, которое может работать длительное время. Важно понимать, что в 3.0 многие данные хранятся иначе (например, регистры учета затрат или налоги).

После завершения основного этапа программа откроется, но работа в ней будет ограничена. В фоне начнут выполняться отложенные обработчики обновления. Посмотрим на этот список через Администрирование — Обслуживание — Результаты обновления программы. Пока все задания не примут статус «Выполнено», формировать отчетность или вводить новые документы крайне не рекомендуется, так как данные могут быть еще не пересчитаны.

Работа с доработками

Если ваша БП 2.0 была изменена (снята с поддержки), стандартный переход не перенесет ваши изменения автоматически. Рассмотрим алгоритм действий:

1. Все новые реквизиты, добавленные в 2.0, должны быть созданы в 3.0 вручную (или расширениями).
2. Код обычных форм полностью несовместим с управляемыми формами. Логику придется переписывать заново.
3. Вместо изменения типовой конфигурации теперь рекомендуется использовать Расширения конфигурации, что значительно упростит последующие обновления 3.0.

Заключение

Подведем итог: если вы столкнулись с разницей релизов, оптимально подождать выхода свежего обновления 3.0 (обычно это занимает несколько дней). Если ждать нельзя — используйте метод переноса данных в копию нужного релиза через XML. Помните о необходимости архивной копии перед любым действием!