Обновление доработанной конфигурации 1С 8.3 без потери своих правок

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

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

1. Подготовка: копии базы и конфигурации до обновления

Перед любым обновлением доработанной конфигурации сделайте три копии. Каждая закрывает свой риск.

Для клиент-серверной базы дополнительно сделайте резервную копию средствами СУБД. Выгрузка .dt большой базы идёт долго, а бэкап SQL восстанавливается быстрее.

Не обновляйте рабочую базу первой. Разверните копию: загрузите .dt в новую пустую базу и проведите всю процедуру на ней. В рабочую базу переносите уже готовую, проверенную конфигурацию.

Что проверить перед стартом

• 🧾 Список доработок. Хорошо, если он ведётся: какие объекты меняли, кто и зачем. Если списка нет — его даст первое же сравнение.
• 🔌 Расширения конфигурации . Посмотрите их перечень в Конфигурация → Расширения конфигурации. Расширения обновляются отдельно, но после обновления основной конфигурации их нужно проверить.
• 🖥 Версия платформы. Каждый релиз конфигурации требует платформу с номером не ниже указанного в описании обновления.

2. Как узнать текущий релиз и получить файлы обновления

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

Дальше нужен дистрибутив обновления. Он бывает двух видов:

Дистрибутивы берут на портале обновлений 1С по договору сопровождения. После запуска установщика файлы попадают в каталог шаблонов конфигураций, путь к нему виден в окне запуска: Настройка → Каталоги шаблонов конфигураций и обновлений.

Почему нельзя перепрыгнуть через релизы

Файл .cfu содержит список версий, с которых на него можно обновиться. Если ваш релиз в этот список не входит, Конфигуратор просто не предложит этот файл.

Варианта два:

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

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

3. Режим поддержки: что значит «снять с поддержки» и как вернуть её

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

После этого каждому объекту можно назначить одно из правил:

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

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

Как восстановить поддержку

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

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

Если текущего релиза под рукой нет, берут ближайший к нему. Различий в сравнении будет больше, и их придётся разбирать вручную.

4. Обновление нетиповой конфигурации: трёхстороннее сравнение и слияние кода

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

Как читать окно сравнения

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

• 🟢 изменён только поставщиком — безопасно взять из новой версии;
• 🔵 изменён только вами — останется вашим, если не трогать;
• 🔴 изменён и вами, и поставщиком — это и есть конфликт, который разбирают руками.

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

Режимы объединения

Для каждого дважды изменённого объекта или модуля выбирают режим:

Ручное слияние модулей

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

1. Откройте сравнение модулей двойным щелчком по строке.
2. Посмотрите различия по процедурам. Платформа умеет сопоставлять код по процедурам, а не построчно — так конфликтов меньше.
3. Для каждой процедуры отметьте, чей вариант брать.
4. Где нужны обе правки — возьмите типовой вариант и после объединения вручную допишите свою вставку.

💡 Свои вставки в типовой код помечайте комментариями-маркерами, например // +++ Компания: доработка печати и // --- Компания. По ним такие места находятся поиском за минуту, а при слиянии их легко отличить от типового кода.

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

Что легко пропустить кроме модулей

Конфликты бывают не только в коде. Проверьте ещё:

• 🔐 Роли. Если вы давали права на свои объекты в типовых ролях, поставщик мог роль изменить. При неудачном слиянии пользователи потеряют доступ к вашим справочникам и отчётам.
• 📋 Состав подписок на события и общих команд. Ваш объект, добавленный в типовую подписку, может выпасть из списка, если взять подписку целиком из новой версии.
• 🗃 Типы реквизитов. Если вы расширили тип реквизита (добавили ссылку на свой справочник), а поставщик тип тоже менял, итоговый состав типов нужно собрать вручную.
• 📑 Макеты печатных форм. Макеты не сливаются построчно: берётся один вариант целиком. Свой макет удобнее держать отдельным объектом.

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

5. Проверка кода после слияния и тестирование на копии

Сначала синтаксис. Запустите Конфигурация → Проверка конфигурации и отметьте:

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

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

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

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

Расширения после обновления

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

6. Перенос в рабочую базу и запуск

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

1. В тестовой базе выполните Конфигурация → Сохранить конфигурацию в файл.
2. Отдельно сохраните конфигурацию поставщика из той же тестовой базы.
3. Выгоните пользователей из рабочей базы и сделайте свежий .dt.
4. В рабочей базе загрузите сохранённую конфигурацию: Конфигурация → Загрузить конфигурацию из файла. Режим поддержки при этом переносится вместе с файлом.
5. Обновите конфигурацию базы данных (F7).
6. Запустите базу в пользовательском режиме и дождитесь обработчиков обновления.

Первые день-два держите выгрузку .dt под рукой и попросите пользователей сообщать о любой странности. Если что-то критично сломалось, откат — загрузка этой выгрузки, а не попытка починить на ходу.

7. Как облегчить следующие обновления нетиповой 1С

Каждое следующее обновление проходит тем легче, чем меньше правок в самой основной конфигурации.

• 🧩 Переносите доработки в расширения. Новые реквизиты, формы, печатные формы, обработчики событий можно вынести в расширение, не трогая типовые объекты. Тогда основная конфигурация остаётся почти типовой, а обновление идёт как у обычной.
• 📦 Новые объекты — свои, а не правки типовых. Нужен новый справочник или документ — создавайте отдельный объект, а не переделывайте типовой.
• 🏷 Маркируйте и документируйте вставки. Список «объект — что изменено — зачем» сокращает разбор конфликтов в разы.
• 🔁 Не копите отставание. Обновлять раз в месяц-два проще, чем раз в год: конфликтов на каждом шаге меньше.
• 🗂 Храните .cf каждого релиза. Они понадобятся для восстановления поддержки и разбора спорных мест.

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

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