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

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

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

Ниже разобраны основные сценарии: восстановление поддержки, обновление через файл поставки, сравнение и объединение с переносом доработок, а также проверка результата и типичные ошибки.

Как понять, что конфигурация снята с поддержки, и оценить объём доработок

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

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

Если отличий немного (несколько модулей и пара реквизитов) — целесообразен перенос доработок вручную после загрузки типовой поставки. Если доработки масштабные (собственные подсистемы, десятки объектов), безопаснее обновляться через сравнение и объединение, аккуратно отмечая, что брать из новой версии, а что оставить своё.

Подготовка: резервная копия и необходимые файлы

Обязательный минимум перед началом работ: выгрузка информационной базы через «Администрирование → Выгрузить информационную базу» в файл .dt. Для файловой базы дополнительно скопируйте каталог базы целиком, для клиент-серверной — сделайте резервную копию средствами СУБД. Выгрузка .dt и копия СУБД — не взаимозаменяемые вещи: при повреждении структуры метаданных иногда проще восстановиться из копии СУБД.

Далее подготовьте дистрибутивы. Понадобится полный cf-файл поставки той версии, до которой обновляете (а если разрыв версий большой — возможно, промежуточные релизы). Дистрибутивы скачиваются с портала 1С при наличии действующего договора сопровождения или у франчайзи. Убедитесь, что версия платформы соответствует требованиям целевого релиза — обычно они указаны в сопроводительной документации к обновлению.

Способ 1. Восстановление поддержки загрузкой типовой конфигурации

Этот способ подходит, когда доработки минимальны или их список известен, и вы готовы перенести их заново после обновления. Суть: база полностью заменяется типовой конфигурацией из cf-файла поставки, после чего становится стандартной и обновляется штатно.

Порядок действий: откройте конфигуратор на копии базы, выполните «Конфигурация → Загрузить конфигурацию из файла» и укажите cf-файл поставки нужного релиза. На вопрос о постановке на поддержку ответьте утвердительно. После загрузки выполните обновление конфигурации базы данных (F7) с принятием изменений.

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

Способ 2. Обновление через сравнение и объединение с файлом поставки

Это основной безопасный сценарий для баз с доработками. В меню «Конфигурация → Поддержка → Обновить конфигурацию» (или «Конфигурация → Сравнить, объединить с конфигурацией из файла», если первый пункт недоступен) укажите cf-файл нового релиза. Откроется окно сопоставления объектов.

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

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

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

Большой разрыв версий и обновление через промежуточные релизы

Если база не обновлялась несколько лет, прыгнуть сразу на последний релиз часто нельзя: обработчики обновления данных рассчитаны на последовательный переход. В сопроводительных файлах дистрибутива (обычно 1cv8upd.htm или аналогичный) указано, с каких версий допустимо обновление на данный релиз.

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

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

Сравнение вариантов

Загрузка типовой cf

Быстро и надёжно, но удаляет все доработки и добавленные объекты с данными

Сравнение и объединение

Сохраняет доработки, но требует ручного разбора конфликтов и внимательности

Перенос данных в чистую базу

Подходит при очень старых версиях и больших доработках; требует настройки правил переноса

Проверка результата после обновления

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

Затем выполните контрольные проверки: проведите типовой документ каждого ключевого вида, сформируйте основные отчёты и сверьте итоги с копией базы до обновления (оборотно-сальдовую ведомость, остатки склада, взаиморасчёты). Проверьте работу доработок: собственные печатные формы, обмены, дополнительные отчёты.

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

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

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

Обработчики обновления

Норма

Все отложенные обработчики завершены без ошибок

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

Обработчики зависли или завершились с ошибками

Итоги учёта

Норма

ОСВ и остатки совпадают с копией до обновления

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

Расхождения в остатках и оборотах

Доработки

Норма

Собственные объекты и обработки работают как раньше

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

Ошибки при открытии форм, не работают обмены и печатные формы

Типичные ошибки и ограничения самостоятельной работы

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

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

Граница самостоятельной работы проходит там, где начинаются массовые конфликты при объединении (сотни изменённых объектов), нестандартные доработки проведения и обменов, или когда база содержит данные, потеря которых критична для бизнеса. В таких случаях разумнее привлечь специалиста по 1С, предоставив ему копию базы и список доработок.

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

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

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

Где взять cf-файл поставки нужного релиза?

Полные дистрибутивы конфигураций доступны на портале 1С при действующем договоре сопровождения (ИТС) или через партнёра-франчайзи. Для некоторых конфигураций полный cf-файл можно получить, установив шаблон обновления и выгрузив конфигурацию поставщика из созданной на его основе пустой базы.

Что делать, если при объединении очень много конфликтов?

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

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

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

Сколько времени занимает обновление большой базы?

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

Что делать, если после обновления отчёты показывают неверные данные?

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