Как обновить нетиповую базу 1С и не потерять доработки

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

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

Ниже — рабочий порядок действий, который подходит для типовых конфигураций с доработками (1С:Бухгалтерия, 1С:Управление торговлей, 1С:ERP, ЗУП и другие), обновляемых через конфигуратор вручную.

Оцените объём доработок до начала работы

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

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

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

Сделайте резервную копию и подготовьте тестовую базу

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

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

Получите дистрибутив нового релиза

Нетиповую конфигурацию обновляют не через интернет-сервис «обновление из программы», а вручную через файл конфигурации поставщика. Скачайте полный дистрибутив нужного релиза с портала 1С или получите у партнёра, установите его шаблон (файл setup.exe из дистрибутива), после чего в каталоге шаблонов появится файл 1Cv8.cf новой версии.

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

Выполните сравнение и объединение конфигураций

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

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

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

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

1. 1
   Сделайте копию базы и разверните тестовую
2. 2
   Откройте «Поддержка → Обновить конфигурацию» и укажите файл 1Cv8.cf нового релиза
3. 3
   В окне сравнения снимите автоотметку и пройдите по всем изменённым объектам
4. 4
   Неизменённые вами объекты возьмите из конфигурации поставщика
5. 5
   Изменённые объекты объедините, модули разберите построчно
6. 6
   Выполните объединение и обновите конфигурацию базы данных (F7)
7. 7
   Запустите базу в режиме предприятия и дождитесь отработки обработчиков обновления

Перенесите внешние доработки и проверьте расширения

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

Расширения конфигурации после обновления нередко отключаются с ошибкой несовместимости: платформа помечает их, если изменились заимствованные объекты. Откройте список расширений («Все функции → Стандартные → Управление расширениями конфигурации» или через конфигуратор), устраните конфликты и включите заново.

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

Протестируйте результат и перенесите обновление на рабочую базу

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

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

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

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

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

Запуск базы и версия в «О программе»

Норма

База открывается, указан новый релиз

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

Ошибки при входе, старая версия

Очередь отложенных обработчиков

Норма

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

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

Есть зависшие или упавшие обработчики

Доработанные объекты

Норма

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

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

Ошибки «поле не обнаружено», пропали реквизиты

Внешние отчёты и расширения

Норма

Подключены, выполняются без ошибок

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

Расширения отключены, обработки падают

Обмены данными

Норма

Синхронизация проходит без ошибок

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

Ошибки формата, не выгружаются объекты

Типичные ошибки при обновлении нетиповой базы

Отдельная ошибка — обновляться «на всякий случай» на каждый релиз. Для нетиповой базы каждое обновление — это трудозатраты на перенос доработок. Разумная практика — обновляться при выходе релизов с нужными изменениями (законодательство, отчётность, исправление критичных ошибок) и пропускать промежуточные, если порядок обновления это позволяет.

Когда стоит привлечь специалиста

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

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

Маршрут решения

Как выбрать действие

Доработок меньше десятка, все известны и задокументированыОбновляйте самостоятельно на тестовой копии по инструкции выше

Доработки делал сторонний программист, документации нетСначала сделайте сравнение с типовой конфигурацией и инвентаризируйте изменения

Конфигурация полностью снята с поддержки, сотни изменённых объектовПривлекайте разработчика 1С; рассмотрите вариант возврата к типовой с переносом доработок в расширения

Нужен только новый регламентированный отчётПроверьте, нельзя ли обойтись внешней обработкой отчёта без обновления всей конфигурации

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

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

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

Что произойдёт с данными в базе при обновлении?

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

Сохранятся ли доработки, если просто загрузить новую конфигурацию полностью?

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

Как понять, какие объекты доработаны, если истории изменений нет?

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

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

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

Можно ли вообще отказаться от обновлений?

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