Переход со старых редакций программных продуктов 1С на актуальные версии — задача, с которой рано или поздно сталкивается любой специалист. Особую сложность представляют случаи, когда база данных не обновлялась в течение многих лет. Например, переход с конфигурации «Бухгалтерия предприятия» редакции 2.0 (образца 2012 года, релизы уровня 2.0.32.4) на современную редакцию 3.0.
В этой статье мы подробно разберем, как избежать критических ошибок при таком переходе, как автоматизировать рутинный процесс накатывания десятков промежуточных обновлений и правильно подготовить базу данных к переходу, чтобы не потерять накопленный учет за прошлые годы.
Проанализируем базовый механизм того, как 1С выполняет обновление конфигурации. Многие начинающие специалисты совершают критическую ошибку: они скачивают цепочку обновлений и последовательно накатывают файлы .cfu (или один большой .cf) в Конфигураторе один за другим, не запуская систему в режиме «1С:Предприятие».
Выясним, почему так делать категорически нельзя. Процесс обновления конфигурации 1С состоит из двух принципиально разных этапов:
Если выполнить обновление на 20 релизов вперед только в Конфигураторе и лишь в самом конце запустить пользовательский режим, система попытается выполнить обработчики только для последнего релиза. В результате промежуточные обработчики будут пропущены. Данные за старые периоды не конвертируются должным образом, учет превратится в «тыкву», а при запуске программы мы гарантированно получим критические ошибки СУБД или нарушения логической целостности базы данных.
Правило успешного обновления: после каждого шага обновления в Конфигураторе (клавиша F7) мы обязаны запустить базу в режиме «1С:Предприятие» под пользователем с полными правами, дождаться завершения работы всех регламентных обработчиков обновления и только после этого переходить к следующему релизу.
Последовательное скачивание, распаковка и ручное обновление через Конфигуратор двух десятков релизов — это колоссальная потеря времени. Рассмотрим два эффективных способа ускорения этого процесса.
Вместо использования мелких файлов обновлений .cfu, мы можем использовать полные файлы конфигурации .cf опорных (узловых) релизов. Фирма 1С для каждой ветки выпускает ключевые релизы, на которые можно обновляться с очень старых версий. Мы можем обновить базу в 2–3 крупных шага вместо 20 мелких, предварительно сверившись с таблицей совместимости релизов на официальном портале поддержки 1С.
Для минимизации ручного труда рекомендуется использовать специализированный инструмент — «Обновлятор-1С». Это внешняя утилита, которая умеет выполнять всю рутинную работу в автоматическом режиме:
Когда база успешно обновлена до финального релиза ветки 2.0 (например, до одного из релизов семейства 2.0.66.х или 2.0.67.х), наступает этап непосредственного перехода на редакцию 3.0. Здесь нас подстерегает важный нюанс, связанный с правами доступа.
В редакции 3.0 используется совершенно иная система разграничения прав и ролей на управляемых формах. Если просто запустить обновление, программа заблокирует вход пользователю. Чтобы этого не произошло, выполним подготовительные действия в старой базе:
Администрирование — Пользователи.Прочие.Полные права установлена специальная роль «Администратор системы (для перехода на ред. 3.0)».Без этой роли первый же запуск новой базы в пользовательском режиме завершится ошибкой нарушения прав доступа, и процесс обновления зависнет на середине.
Обратим внимание на то, что для перехода с БП 2.0 на БП 3.0 нельзя использовать стандартный файл обновления новой редакции. На портале 1С необходимо скачать специальный тип дистрибутива, который называется «Дистрибутив обновления для перехода с редакции 2.0».
Внимательно изучим таблицу совместимости релизов. Переход возможен только с определенных версий 2.0 на строго определенные версии 3.0. Попытка обновиться на несовместимый релиз приведет к повреждению структуры метаданных.
Поскольку база данных не обновлялась с 2012 года, в ней почти наверняка накопились скрытые ошибки, битые ссылки и логические несоответствия. Перед началом любых манипуляций обязательно выполним комплекс профилактических работ.
Разберем этот процесс по шагам:
.dt через меню Администрирование — Выгрузить информационную базу или просто скопируем файл 1Cv8.1CD для файловой базы.bin) и запустим утилиту тестирования файлов базы данных chdbfl.exe. Поставим галочку «Исправлять обнаруженные ошибки» и запустим проверку физической целостности таблиц.Администрирование — Тестирование и исправление. Рекомендуется выбрать следующие опции:
Склады реквизит Тип склада стал строго обязательным. Напишем простой скрипт для автоматического поиска незаполненных значений.Для примера рассмотрим код внешней обработки, который поможет быстро проанализировать справочник складов на наличие пустых типов перед началом масштабного обновления:
ВыборкаСкладов = Справочники.Склады.Выбрать();
КоличествоОшибок = 0;
Пока ВыборкаСкладов.Следующий() Цикл
Если Не ЗначениеЗаполнено(ВыборкаСкладов.ТипСклада) Тогда
КоличествоОшибок = КоличествоОшибок + 1;
Сообщить("Внимание! У склада '" + ВыборкаСкладов.Наименование + "' не заполнен тип склада!");
КонецЕсли;
КонецЦикла;
Если КоличествоОшибок = 0 Тогда
Сообщить("Проверка складов завершена успешно. Ошибок не обнаружено."); Иначе
Сообщить("Всего обнаружено ошибок: " + КоличествоОшибок + ". Заполните типы складов перед обновлением!");
КонецЕсли;
Проанализируем ситуацию, когда база данных за прошедшие 10 лет накопила слишком много ошибок, содержит следы некорректных ручных корректировок или была сильно кастомизирована (изменена программистами). В этом случае стандартный путь обновления может стать слишком трудоемким, а результат — непредсказуемым.
В подобных сценариях оптимальным решением является не обновление старой конфигурации, а перенос данных в абсолютно чистую базу «Бухгалтерия предприятия 3.0». Рассмотрим, как это сделать:
Этот подход имеет ключевое преимущество: мы начинаем вести учет в новой редакции 3.0 без «мусора» прошлых лет, неактуальных документов за предыдущие десятилетия и накопленных логических ошибок базы данных.