← На главную

При переходе с устаревшей редакции 2.0 на современную 3.0 технические специалисты часто сталкиваются с неприятной ситуацией: установленный релиз «двойки» оказывается «слишком новым» для текущего дистрибутива обновления «тройки». Например, у вас установлена версия 2.0.66.71, а файл обновления для перехода поддерживает только версии до 2.0.66.70 включительно. В результате конфигуратор просто не видит доступных обновлений в папке шаблонов.

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

Почему конфигуратор не видит обновление?

Разберем техническую сторону вопроса. Когда мы выбираем пункт меню Конфигурация — Поддержка — Обновить конфигурацию и указываем поиск в каталогах шаблонов, система обращается к специальному файлу 1cv8.cup, который находится внутри дистрибутива обновления. Этот файл является текстовым и содержит жестко прописанные соответствия: с каких номеров версий на какой номер версии можно перейти.

Если фирма «1С» выпустила экстренный «сервисный» релиз для 2.0 (например, с исправлениями в отчетности), а переходный дистрибутив для 3.0 еще не успел выйти, ваш номер версии в файле 1cv8.cup будет отсутствовать. Конфигуратор считает такой переход небезопасным и скрывает его от пользователя.

Способ 1. Штатное ожидание (Самый безопасный вариант)

Проанализируем самый надежный путь, предложенный в обсуждении. Если ситуация не является критической и вам не нужно «вчера» сдать отчетность из новой программы, лучшим решением будет дождаться выхода следующего релиза 3.0. Обычно поддержка новых сервисных релизов 2.0 появляется в «тройке» в течение 1–2 недель.

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

Способ 2. Технический «откат» версии через снятие с поддержки

Если ждать возможности нет, рассмотрим метод временного понижения номера версии вашей конфигурации. Это позволит «обмануть» конфигуратор и запустить процесс обновления.

Разберем этот процесс по шагам:

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

Важное предостережение: Этот метод безопасен только в том случае, если между релизами .70 и .71 не было изменений в структуре таблиц базы данных. Если в .71 добавили новый реквизит, а вы «откатили» номер и обновились на 3.0, данные этого реквизита будут потеряны.

Способ 3. Переход через полное сравнение и объединение (Загрузка CF)

Существует мнение, что можно просто «накатить» полный файл конфигурации (.cf) от редакции 3.0 на базу 2.0. Рассмотрим, почему этот метод считается экстремальным и требует высокой квалификации.

Механизм обновления через .cf игнорирует проверки файла 1cv8.cup. Однако переход с 2.0 на 3.0 — это не просто замена объектов, это сложнейшая реструктуризация. Если вы используете этот метод, выполните следующие действия:

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

Способ 4. Начало «новой жизни» (Перенос остатков)

В некоторых случаях (особенно если база 2.0 сильно доработана или в ней накопилось много ошибок учета) мы рекомендуем рассмотреть вариант чистого перехода. Вместо обновления существующей базы выполняется перенос данных в новую, пустую базу БП 3.0.

Проанализируем преимущества этого подхода:

• Вы получаете чистую, типовую базу без «хвостов» старых доработок.
• Переносятся только необходимые данные: нормативно-справочная информация (НСИ) и остатки на начало периода (например, на начало года или квартала).
• Игнорируются любые проблемы с несовместимостью номеров релизов.

Для реализации этого метода используйте встроенную обработку выгрузки данных, которая обычно находится в составе конфигурации 2.0 или поставляется вместе с дистрибутивом 3.0 в папке AddFiles\Перенос данных из БП20.

Резюме и рекомендации

Выясним, какой путь выбрать именно вам:

1. Если вы не торопитесь — ждите официального обновления. Это сэкономит время на отладку возможных ошибок.
2. Если обновление нужно срочно и база типовая — используйте способ со сменой номера версии в конфигураторе, предварительно проверив состав изменений в релизе .71 на сайте техподдержки.
3. Если база содержит много доработок — забудьте про автоматическое обновление. Вам потребуется сначала привести доработки в соответствие с архитектурой 3.0 (желательно вынести их в расширения), и только потом выполнять переход.

Помните, что переход с 2.0 на 3.0 — это «билет в один конец». Обратного штатного перехода не существует, поэтому качество проверки данных на копии после обновления — ваш главный приоритет. Проверьте ОборотноСальдоваяВедомость до и после перехода, убедитесь, что все документы СчетФактураВыданный корректно привязаны к документам-основаниям и регистры НДС заполнены правильно.