Доработанная база 1С и новый релиз: обновляем без потери своих правок

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

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

1. Подготовка базы к обновлению с доработками

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

Откройте базу в Конфигураторе и выберите Конфигурация → Поддержка → Настройка поддержки. В окне видно:

• 🔒 «Конфигурация находится на поддержке», изменения не включены — база типовая, доработок в основной конфигурации нет. Её можно обновлять штатно.
• ✏️ Включена возможность изменения — объекты могут быть доработаны. Нужно сравнение и объединение.
• ✂️ Конфигурация снята с поддержки — платформа «не помнит» исходную версию поставщика. Обновление сначала потребует вернуть её на поддержку (об этом ниже).

Дальше проверьте три вещи:

1. Текущий релиз. Справка → О программе в режиме «Предприятие» или свойства корня конфигурации в Конфигураторе.
2. Цепочку обновлений. Файл .cfu ставится только на определённые предыдущие релизы. Если ваш релиз слишком старый, понадобится пройти промежуточные версии по очереди или взять полный дистрибутив .cf.
3. Версию платформы. У каждого релиза есть минимальный номер платформы. Если установленная платформа ниже — сначала обновите её.

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

2. Резервная копия: выгрузка базы в .dt и конфигурации в .cf

Обе копии делаются из Конфигуратора и решают разные задачи.

Без выгрузки в .dt обновление доработанной базы не начинайте. Если объединение пройдёт неудачно, а копии нет, восстановить ваши правки будет почти невозможно.

Порядок выгрузки:

1. Попросите всех выйти из базы. Выгрузка .dt требует, чтобы других сеансов не было.
2. Выполните Администрирование → Выгрузить информационную базу, укажите папку и имя файла с датой, например buh_2026-10-07_pered_obnovleniem.dt.
3. Сразу после этого сохраните конфигурацию в .cf.
4. Проверьте, что файлы появились и их размер не нулевой.

Для клиент-серверной базы дополнительно сделайте резервную копию средствами СУБД — она надёжнее для больших баз.

3. Загрузка нового релиза в Конфигураторе

Скачайте файл обновления с портала поставщика (по подписке ИТС) и распакуйте дистрибутив — в каталоге шаблонов появятся файлы 1cv8.cfu и 1cv8.cf.

Дальше:

1. Убедитесь, что в настройке поддержки включена возможность изменения. Если её нет, а доработки есть, значит, правки сделаны в расширениях — тогда основную конфигурацию можно обновлять штатно.
2. Выберите Конфигурация → Поддержка → Обновить конфигурацию.
3. Укажите вариант «Выбор файла обновления» и файл .cfu нужного релиза. Если релиз не входит в цепочку, используйте полный .cf.
4. Подтвердите. Платформа загрузит новую конфигурацию поставщика и откроет окно сравнения трёх конфигураций.

В окне сравнения три участника:

• 📦 Основная конфигурация — ваша, с доработками.
• 🆕 Новая конфигурация поставщика — то, что пришло в обновлении.
• 📁 Старая конфигурация поставщика — типовая версия, на которую у вас ставились правки.

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

Если конфигурация снята с поддержки

Вернуть её на поддержку можно без потери правок:

1. Найдите полный .cf того же релиза, что сейчас в базе.
2. Выполните Конфигурация → Сравнить, объединить с конфигурацией из файла и укажите этот файл.
3. На вопрос о постановке на поддержку ответьте «Да».
4. В окне сравнения снимите все флажки объединения, чтобы ничего не перезаписать, и выполните объединение.

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

Если нужно пройти несколько релизов подряд

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

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

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

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

4. Объединение конфигураций: как сохранить доработки

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

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

Для каждого объекта выберите режим:

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

Перед нажатием кнопки выполнения ещё раз просмотрите список с флажками. Объект без флажка не изменится вовсе — ни в вашу, ни в поставщика пользу.

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

Конфликт — это место, где вы и поставщик изменили один и тот же фрагмент по-разному. Типичные ситуации и что с ними делать:

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

6. Завершение обновления и проверка работы базы

Объединение изменило только конфигурацию в Конфигураторе. Сами данные база увидит после обновления конфигурации базы данных.

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

Затем пройдите по своим доработкам:

Для сверки сумм удобно сформировать в тестовой копии до обновления и в обновлённой базе одни и те же отчёты, например оборотно-сальдовую ведомость за прошлый закрытый месяц. Цифры должны совпасть.

7. Если доработки всё же пропали

Ситуация неприятная, но исправимая, если вы сделали копии.

• 🔁 Пропали отдельные правки. Выполните Конфигурация → Сравнить, объединить с конфигурацией из файла и укажите .cf, сохранённый перед обновлением. Отметьте флажками только потерянные объекты или процедуры и объедините.
• 🧩 Сломалось многое, база работает некорректно. Загрузите .dt через Администрирование → Загрузить информационную базу и начните обновление заново, на тестовой копии.
• 📂 Копии нет, но есть старая резервная копия базы. Разверните её в отдельную базу, сохраните из неё конфигурацию в .cf и используйте как источник для объединения.

Загрузка .dt полностью заменяет текущую базу. Всё, что пользователи ввели после выгрузки, пропадёт. Если с момента обновления прошёл рабочий день, сначала перенесите правки через .cf, а к .dt прибегайте в крайнем случае.

Как не попадать в это снова

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

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