Как обновить нетиповую конфигурацию 1С 8.3

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

Сложность процедуры зависит от трёх факторов: глубины доработок (изменены только формы и отчёты или переписаны модули и структура данных), количества пропущенных релизов и того, велась ли история изменений. Чем больше правок и чем длиннее «хвост» пропущенных версий, тем выше вероятность конфликтов при объединении.

Ниже разобран полный цикл обновления: подготовка и анализ доработок, выбор способа объединения, разрешение конфликтов, обновление базы данных и проверка результата. Материал ориентирован на конфигурации, находящиеся на поддержке с возможностью изменения, — самый распространённый случай для доработанных решений.

Подготовка: копия базы и анализ доработок

Первое действие — полная резервная копия. Для файловой базы достаточно скопировать каталог при остановленной работе пользователей, для клиент-серверной — сделать выгрузку через конфигуратор (Администрирование → Выгрузить информационную базу) или штатный бэкап средствами СУБД. Выгрузка в .dt не заменяет бэкап СУБД при больших объёмах, но для большинства баз подходит как страховка.

Далее нужно понять, что именно доработано. Откройте конфигуратор и выполните «Конфигурация → Сравнить конфигурации», сравнив текущую конфигурацию с конфигурацией поставщика (Конфигурация → Поддержка → Настройка поддержки → Сравнить с конфигурацией поставщика). Различия покажут все объекты, которые менялись относительно типовой версии. Зафиксируйте этот список — он станет чек-листом при разрешении конфликтов.

Если доработки никто не документировал, полезно выгрузить отчёт о сравнении в файл и раздать его разработчикам или внедренцу, которые делали правки. Обновление «вслепую», когда никто не знает назначение изменённых модулей, — главный источник потери функциональности.

Снятие с поддержки и постановка на поддержку: что нужно знать

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

Проверить состояние можно через «Конфигурация → Поддержка → Настройка поддержки». Если там указан поставщик и стоит режим с возможностью изменения — всё в порядке. Если конфигурация уже снята с поддержки, обновление всё ещё возможно, но потребует тройного сравнения: ваша конфигурация, старая типовая версия, новая типовая версия.

Загрузка нового релиза и запуск сравнения

Новый релиз распакуйте из комплекта поставки (файл 1cv8.cfu или полный дистрибутив). Затем в конфигураторе откройте «Конфигурация → Поддержка → Обновить конфигурацию». Платформа предложит найти обновление автоматически или указать файл вручную — для нетиповой конфигурации надёжнее указать .cfu-файл явно.

Если релиз пропущен не один, обновляться нужно последовательно через промежуточные версии, если этого требует поставщик (это указано в файле поставки, в списке версий, с которых возможно обновление). Попытка «перепрыгнуть» через несколько релизов, когда переход не поддержан, приведёт к отказу обновления или ошибкам обработчиков перехода.

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

1. 1
   Сделать резервную копию и развернуть тестовую базу
2. 2
   Зафиксировать список доработок сравнением с конфигурацией поставщика
3. 3
   Загрузить .cfu нового релиза через «Обновить конфигурацию»
4. 4
   В окне объединения разрешить конфликты, сохраняя свои доработки
5. 5
   Выполнить объединение и обновить конфигурацию базы данных
6. 6
   Проверить обработчики обновления и протестировать ключевые операции

Разрешение конфликтов при объединении

Ключевой принцип: платформа по умолчанию предлагает взять объекты из новой конфигурации поставщика, но для доработанных вами объектов это означает потерю правок. Пройдитесь по всем объектам, помеченным как изменённые с обеих сторон, — их видно по фильтру «Показывать только различающиеся».

Для изменённых модулей используйте построчное сравнение: двойной клик по объекту открывает текстовое сравнение, где можно перенести свои фрагменты кода в новую версию модуля. Не берите модуль целиком «из поставщика» и не оставляйте целиком «свой» — почти всегда нужен гибрид: новые функции поставщика плюс ваши правки.

Для форм и макетов ручное слияние сложнее: если форма сильно доработана, иногда проще принять форму поставщика и заново повторить свои изменения. Для метаданных (реквизиты, измерения, ресурсы) правило проще: свои добавленные реквизиты не должны пропасть, а реквизиты поставщика нужно принять — иначе обработчики обновления и типовой код могут отработать с ошибками.

Полезное правило при разборе модулей: сначала принять версию поставщика, а затем вручную перенести свои изменённые процедуры и функции из сохранённой копии. Помечайте свои блоки комментариями с префиксом (например, // ДОРАБОТКА) — при следующем обновлении вы найдёте их за минуты, а не за часы.

Обновление конфигурации базы данных

После объединения выполните «Конфигурация → Обновить конфигурацию базы данных». Платформа покажет список реструктуризации: добавленные и изменённые объекты. Проверьте, что в списке нет удаления ваших доработанных реквизитов или объектов — удаление данных в этом окне означает безвозвратную потерю информации.

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

Контрольные точки

Как проверить результат

Журнал регистрации после первого запуска

Норма

Обработчики обновления завершены, ошибок нет

Тревожный признак

Ошибки в обработчиках или обновление «зависло» на одном шаге

Доработанные документы и отчёты

Норма

Открываются, проводятся, печатные формы работают

Тревожный признак

Ошибки «Метод не обнаружен», пустые или битые формы

Типовые операции

Норма

Стандартные отчёты и документы работают как раньше

Тревожный признак

Ошибки в типовых механизмах после слияния модулей

Тестирование и типичные ошибки

Тестирование начинается с ключевых бизнес-процессов: проведите документы каждого доработанного вида, сформируйте основные отчёты, проверьте обмены с другими системами, если они есть. Особое внимание — местам, где ваши правки пересекались с изменениями поставщика в одних и тех же модулях: именно там прячутся логические ошибки, которые не видны при компиляции.

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

Частые вопросы

Можно ли обновить нетиповую конфигурацию автоматически через интернет?

Нет. Автоматическое обновление через сервис работает только для типовых конфигураций без изменений. При наличии доработок обновление выполняется вручную через конфигуратор с обязательным разбором конфликтов слияния.

Конфигурация полностью снята с поддержки — что делать?

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

Как не потерять доработки при следующих обновлениях?

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

Чем расширение лучше доработки конфигурации?

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

Обработчики обновления завершились с ошибками — база испорчена?

Не обязательно. Ошибки отдельных обработчиков часто исправляются повторным запуском после устранения причины (например, незаполненного реквизита). Разберите сообщения в журнале регистрации на тестовой копии, устраните причину и повторите обновление. Рабочую базу до выяснения причин не трогайте.