← На главную

Возникает ситуация, когда необходимо обновить нетиповую конфигурацию 1С, например, "Бухгалтерию предприятия", сразу на несколько версий вперед. Самый очевидный, но, как выясняется, неверный путь — это обновить копию базы до финальной версии, сохранить конфигурацию в .cf файл и загрузить его в рабочую базу. Разберем, почему так делать категорически нельзя и какой алгоритм является правильным и безопасным.

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

Почему нельзя "перепрыгивать" через релизы простой заменой конфигурации?

Главный риск такого подхода — пропуск выполнения обработчиков обновления. Это специальные программные механизмы, которые запускаются автоматически при первом входе в программу в пользовательском режиме после каждого обновления конфигурации. Их задача — привести данные в базе в соответствие с новой структурой и логикой программы.

Что именно делают эти обработчики:

• Реструктуризация данных: Они могут изменять структуру таблиц базы данных. Например, данные из одного устаревшего регистра могут переноситься в новый, более актуальный справочник.
• Заполнение новых реквизитов: При добавлении в объекты метаданных новых полей обработчики заполняют их значениями по умолчанию или рассчитывают на основе уже имеющихся данных.
• Актуализация учетных данных: Выполняют пересчет итогов, перепроведение документов или исправление данных в соответствии с изменениями в законодательстве или бизнес-логике.

Посмотрим на наглядный пример. Представим, что в релизе 3.0.100 у вас есть регистр сведений, где хранятся важные данные. В следующем релизе, 3.0.101, разработчики 1С решают, что этот регистр больше не нужен, а данные должны храниться в новом справочнике.

1. При обновлении на релиз 3.0.101 срабатывает обработчик, который:
   • Создает новый справочник.
   • Копирует все данные из старого регистра в этот справочник.
   • Переименовывает старый регистр, добавляя префикс, например, Удалить.... Данные пока не удаляются.
2. В релизе 3.0.102 разработчики окончательно удаляют старый регистр Удалить... из конфигурации.

Если вы обновляетесь последовательно (100 -> 101 -> 102), то все происходит корректно: данные переносятся, и система продолжает работать. Но если вы "перепрыгнете" с релиза 3.0.100 сразу на 3.0.102, загрузив финальный .cf файл, произойдет следующее: обработчик переноса данных из релиза 3.0.101 будет пропущен. Система увидит, что в новой конфигурации старого регистра нет, и просто удалит его вместе со всеми данными. В итоге вы получите пустой новый справочник и безвозвратную потерю информации.

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

Правильный и безопасный алгоритм обновления нетиповой конфигурации

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

1. Создание резервной копии. Это золотое правило. Перед любыми манипуляциями с рабочей базой обязательно создайте ее полную резервную копию (выгрузку в файл .dt). Это ваша страховка на случай любых непредвиденных проблем.

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

3. Последовательное обновление копии. Найдите на сайте поддержки пользователей 1С рекомендуемую цепочку обновлений для вашей конфигурации.

   1. Запустите копию базы в режиме "Конфигуратор".
   2. Загрузите файл конфигурации (.cf) первого релиза из цепочки обновлений (меню Конфигурация -> Загрузить конфигурацию из файла...).
   3. После загрузки обновите конфигурацию базы данных (нажатием F7 или через меню Конфигурация -> Обновить конфигурацию базы данных).
   4. Ключевой шаг: Запустите базу в режиме "1С:Предприятие". Система обнаружит, что версия изменилась, и начнет выполнение процедур обновления. Дождитесь их полного завершения. Этот процесс может занять продолжительное время.
   5. Проконтролировать ход и результаты можно в разделе: Администрирование – Обслуживание – Результаты обновления и дополнительная обработка данных. Убедитесь, что все процедуры выполнены успешно.
   6. Повторите шаги 2-5 для каждого следующего релиза в цепочке обновлений.

4. Перенос обновлений в рабочую базу. После того как копия успешно обновлена до финальной версии, необходимо перенести изменения в рабочую базу, сохранив при этом ваши доработки. Для этого используется механизм сравнения и объединения.

   1. Сохраните конфигурацию полностью обновленной копии в отдельный .cf файл.
   2. Откройте рабочую базу в режиме "Конфигуратор".
   3. Выберите в меню Конфигурация -> Сравнить, объединить с конфигурацией из файла... и укажите .cf файл, сохраненный на предыдущем шаге.
   4. В открывшемся окне сравнения вы увидите три колонки: текущая конфигурация, новая (из файла) и старая (типовая, на которой основана ваша доработка). Внимательно проанализируйте изменения. Ваша задача — перенести все изменения из новой типовой конфигурации, не затерев при этом собственные доработки. Установите фильтр, чтобы видеть различия, и аккуратно отметьте галочками объекты для переноса. Этот этап требует максимальной концентрации и понимания структуры конфигурации.
   5. После завершения объединения обновите конфигурацию рабочей базы данных (F7).
   6. Запустите рабочую базу в режиме "1С:Предприятие" и, как и в случае с копией, дождитесь полного выполнения всех обработчиков обновления.

Этот метод сложнее и дольше, но только он гарантирует целостность данных и корректность работы нетиповой конфигурации.

Дополнительные рекомендации и современный подход

Опытный специалист может "прыгать"?
Иногда можно услышать, что опытные программисты обновляют базы, пропуская релизы. Это действительно возможно, но требует глубокого анализа. Специалист должен вручную изучить состав изменений в каждом пропущенном релизе, проверить код всех обработчиков обновления и убедиться, что пропуск не затронет используемый в базе функционал и не приведет к потере данных. Для начинающего специалиста такой подход категорически не рекомендуется.

Современный подход — расширения.
Снятие конфигурации с поддержки, особенно такой сложной, как "Бухгалтерия предприятия", — это устаревшая и рискованная практика. Современный и предпочтительный способ доработки — механизм расширений. Он позволяет добавлять новую функциональность, изменять формы и отчеты, не затрагивая основную конфигурацию. Она остается полностью типовой и на поддержке, что позволяет обновлять ее стандартными средствами (через файлы .cfu), а это в разы проще и безопаснее.

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