При обновлении доработанной конфигурации 1С через конфигуратор разработчики часто сталкиваются с двумя вопросами. Первый — чисто технический: почему процесс сравнения и объединения объектов запускается несколько раз? Второй — практический и более рискованный: можно ли сэкономить время и «перепрыгнуть» через несколько промежуточных релизов? Разберем оба этих вопроса подробно, чтобы понять механику платформы и избежать серьезных ошибок в будущем.
На первый взгляд кажется, что для обновления достаточно двух сравнений: сравнить нашу рабочую конфигурацию с новой и объединить их. Однако на самом деле в процессе участвует больше «игроков», и многоэтапное сравнение необходимо для корректного и осознанного объединения изменений.
Рассмотрим, какие конфигурации участвуют в этом процессе:
.cfu или .cf), на которую вы хотите перейти.Теперь проанализируем, какие сравнения и для чего выполняет система:
Основная конфигурация vs Старая конфигурация поставщика
Цель этого сравнения — выявить все ваши доработки. Система анализирует, какие объекты вы добавили, изменили или удалили по сравнению с исходной типовой версией. Результаты этого сравнения позволяют вам четко видеть свои изменения.
Старая конфигурация поставщика vs Новая конфигурация поставщика
Здесь система определяет, что именно изменилось в типовом решении. Какие новые объекты добавили разработчики 1С, какие модули обновили, какие реквизиты переименовали. Это позволяет подготовить отчет об изменениях в новой версии.
Основная конфигурация vs Новая конфигурация поставщика
Это сравнение, по сути, подготавливает итоговое окно, с которым работает разработчик. Система сопоставляет ваши доработки с изменениями поставщика и предлагает варианты для каждого измененного объекта: взять вашу версию, версию поставщика, или объединить их. Именно благодаря предыдущим двум сравнениям платформа может корректно подсветить три состояния объекта: изменен только у вас, изменен только у поставщика, изменен и у вас, и у поставщика.
Итог: многократные сравнения — это не избыточность, а необходимый механизм для подготовки удобного и информативного отчета в окне «Сравнение, объединение». Это позволяет разработчику принимать взвешенные решения по каждому объекту, сохраняя и свои доработки, и новую функциональность от поставщика.
А что с конфигурацией «на замке»?
Если конфигурация полностью типовая и не изменялась (все объекты на поддержке поставщика, «под замком»), то участие программиста в объединении не требуется. В этом случае обновление можно и нужно выполнять в режиме «1С:Предприятие». Сравнения все равно происходят, но автоматически, без вывода окна для разработчика. Процесс проходит быстрее и проще.
Это один из самых частых и опасных вопросов. Ситуация: нужно обновить ЗУП с версии 3.1.27.51 на 3.1.27.93, а между ними есть промежуточный релиз 3.1.27.92. Возникает соблазн пропустить его, чтобы сэкономить время. Делать так категорически не рекомендуется.
Технически платформа может позволить вам загрузить конфигурацию, перескочив через несколько версий. Однако это чревато скрытыми ошибками и, что хуже всего, безвозвратной потерей данных.
Ключ к пониманию проблемы лежит в механизме отложенного обновления данных. После того как вы обновили конфигурацию в конфигураторе, при первом запуске в режиме «Предприятие» запускаются специальные процедуры — обработчики обновления. Они находятся в общих модулях (часто с названием вроде ОбновлениеИнформационнойБазы) и выполняют критически важные задачи по адаптации данных к новой структуре конфигурации.
Самое главное: эти обработчики должны выполняться строго последовательно.
Проанализируем риски на конкретном примере:
Это самая частая и опасная ловушка. Разработчики 1С часто изменяют структуру объектов в несколько этапов.
Сотрудник в ФизическоеЛицо. Чтобы не потерять данные, он не удаляет старый реквизит сразу. Вместо этого он переименовывает его в УдалитьСотрудник, создает новый реквизит ФизическоеЛицо и пишет обработчик обновления, который при переходе на эту версию копирует все данные из УдалитьСотрудник в ФизическоеЛицо..92 и перенесли данные, полностью удаляет реквизит УдалитьСотрудник.Что произойдет, если мы перепрыгнем с .51 сразу на .93?
Ваша база данных содержит данные в реквизите Сотрудник (который в новой конфигурации уже называется УдалитьСотрудник и помечен на удаление). Вы обновляете конфигурацию, и платформа удаляет этот реквизит вместе со всеми данными. Обработчик обновления из пропущенного релиза .92, который должен был перенести данные, не будет выполнен. В результате данные будут безвозвратно утеряны.
Простое сравнение конфигураций .51 и .93 может не показать эту проблему. Вы увидите, что реквизита Сотрудник больше нет, но не увидите, что для его корректного преобразования требовался промежуточный шаг.
Обработчики обновления не только переносят данные. Они могут выполнять сложные преобразования: заполнять новые регистры на основе старых, пересчитывать итоги, обновлять служебные данные. Если пропустить один из шагов этой цепочки, можно получить неконсистентное состояние базы, которое проявится не сразу, а в виде странных ошибок при расчете зарплаты или формировании отчетов через несколько месяцев.
Для многих сложных продуктов, таких как 1С:ERP, фирма "1С" публикует обязательный порядок обновления и указывает ключевые (LTS) версии, пропуск которых недопустим. Это прямое указание на то, что последовательность обновлений критически важна. Даже если для вашей конфигурации такой подробной схемы нет, общий принцип остается тем же. Обновляясь «через релиз», вы действуете на свой страх и риск, и техническая поддержка 1С не сможет вам помочь в случае проблем.
Экономия нескольких часов на пропуске промежуточного релиза может обернуться днями и неделями работ по восстановлению потерянных данных и поиску неуловимых ошибок. Риск абсолютно не оправдан.