Переход с редакции 2.0 на 3.0 для нетиповой «1С:Бухгалтерии предприятия» — это не просто очередное обновление, а масштабный проект по рефакторингу и трансформации данных. Процесс осложняется тем, что в редакции 3.0 полностью изменилась архитектура интерфейса (переход на управляемые формы) и многие внутренние механизмы. Разберем подробно, как выстроить стратегию перехода, избежать типичных ошибок и сохранить все доработки.
Прежде чем приступать к техническим действиям, проанализируем текущее состояние базы 2.0. Рассмотрим ситуацию: в базе добавлены справочники, реквизиты, планы счетов и изменены типовые формы. Первоочередная задача — выяснить у пользователей, какие из этих доработок реально используются в работе. Часто бывает, что 80% кастомного функционала уже не актуальны или в редакции 3.0 они реализованы в типовом варианте.
Проанализируем добавленные объекты. Если функционал можно реализовать через Расширения конфигурации или Дополнительные отчеты и обработки, лучше отказаться от внесения изменений в основную конфигурацию 3.0. Это значительно упростит последующую поддержку и автоматические обновления.
Перед началом перехода выполним обязательные регламентные операции в исходной базе:
Рассмотрим два основных варианта технического обновления, которые чаще всего обсуждаются специалистами.
Вариант 1: Обновление через «снятие с поддержки»
Суть метода заключается в том, чтобы привести рабочую базу к типовому виду, обновить её спецдистрибутивом, а затем заново внести изменения. Разберем по шагам:
.cfu или .cf для перехода).Вариант 2: Прямое объединение с подготовленным файлом
Этот способ часто оказывается быстрее. Мы берем типовой файл .cf редакции 3.0, вносим в него все необходимые доработки (создаем пустые справочники с теми же именами, добавляем реквизиты) и используем его для сравнения и объединения с рабочей базой 2.0. Этот метод позволяет точечно управлять процессом переноса метаданных.
Главная сложность перехода — обычные формы. В редакции 3.0 они не работают. Проанализируем, как правильно адаптировать объекты:
Если у вас есть добавленные справочники, их формы нужно переделать с нуля. Не пытайтесь «конвертировать» старые формы. Создадим новые Управляемые формы, назначим их основными. Старые формы можно не удалять сразу, чтобы иметь возможность подглядывать в логику кода, но работать они не будут.
Важно помнить о рефакторинге кода в модулях. Вызовы типа Предупреждение() или Вопрос() в модулях объектов приведут к ошибкам. Весь код должен быть разделен на клиентскую и серверную части. Рассмотрим пример правильного обращения к серверным данным:
&НаКлиенте
Процедура КомандаВыполнить(Команда)
Результат = ВыполнитьРасчетНаСервере();
Сообщить(Результат);
КонецПроцедуры
&НаСервере
Функция ВыполнитьРасчетНаСервере()
// Здесь размещаем логику работы с данными базы
Возврат Справочники.Номенклатура.НайтиПоНаименованию("Товар").Артикул;
КонецФункции
Часто при переходе возникает ошибка: «На удаляемый объект есть ссылки в объектах основной конфигурации». Это происходит из-за того, что в 3.0 удалены многие старые общие модули (например, УниверсальныеМеханизмы).
Выясним причину: если ваши доработки в 2.0 ссылаются на эти модули, обновление заблокируется. Выход один — перед запуском обновления в конфигураторе 2.0 нужно найти все ссылки на удаляемые в будущем типовые модули и закомментировать или переписать эти участки кода под стандарты БСП (Библиотеки стандартных подсистем).
Посмотрим на процесс с точки зрения системного администрирования. Переход с 2.0 на 3.0 инициирует масштабную перестройку таблиц базы данных. Если ваша база работает на MS SQL Server, размер временной базы TempDB может увеличиться в несколько раз. Проанализируем ситуацию: для базы объемом 50 Гб может потребоваться до 150-200 Гб свободного места для временных файлов SQL во время реструктуризации. Если места не хватит, вы получите трудночитаемую ошибку формата SDBM или конфликт блокировок.
После успешного технического обновления работа только начинается. Выясним, как изменились данные:
Подводя итог, отметим: наиболее безопасный путь для сильно кастомизированной базы — это предварительная свертка остатков в 2.0 и последующий перенос данных в чистую типовую базу 3.0 с использованием расширений для сохранения ваших уникальных наработок.