К статье
Практический материал

Разработка и Конфигурация · 12 мин

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

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

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

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

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

Что означает «конфигурация на поддержке» и зачем её возвращать

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

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

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

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

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

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

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

Сценарий 1: возврат на поддержку с сохранением изменённых объектов

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

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

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

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

Сценарий 2: полный возврат к типовой конфигурации поставщика

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

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

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

Два сценария возврата

С сохранением изменённых объектов

Подходит, если доработки ещё нужны. Обновления ставятся, но изменённые объекты требуют ручного сопоставления при каждом релизе.

Полный возврат к типовой

Подходит при переносе доработок в расширения. Обновления полностью автоматические, но все правки типовых объектов теряются.

Возврат через расширения

Гибрид: ядро типовое, логика в расширении. Оптимален в долгосрочной перспективе, но требует первоначальной работы по переносу.

Перенос доработок в расширение перед возвратом на поддержку

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

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

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

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

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

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

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

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

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

Окно настройки поддержки
Норма

Указан поставщик и версия, конфигурация на поддержке

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

Окно пустое или кнопка постановки на поддержку недоступна

Тестовое обновление на копии
Норма

Обновление идёт штатно, ручное сопоставление только для известных доработок

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

Сравнение показывает тысячи отличающихся объектов

Конфигурация базы данных
Норма

Обновление конфигурации БД выполнено без ошибок реструктуризации

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

Предупреждения об удалении реквизитов с данными

Работа пользователей
Норма

Документы проводятся, отчёты сходятся с прежними данными

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

Ошибки в модулях, расхождения в отчётах

Типичные ошибки и ограничения

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

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

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

Типичные ошибки
01
Загрузка cf-файла другой версии — рассинхронизация конфигурации и данных, сложная реструктуризация
02
Отсутствие резервной копии — невозможность отката при потере доработок
03
Полный возврат к типовой до переноса доработок в расширение — потеря рабочей функциональности
04
Игнорирование окна реструктуризации — удаление добавленных реквизитов вместе с данными
05
Работа без монопольного доступа — ошибки обновления конфигурации БД и блокировки
Итог

Что важно запомнить

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

Частые вопросы о возврате конфигурации на поддержку

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

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

Что будет с данными в базе при загрузке конфигурации из файла?

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

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

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

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

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

Почему после возврата на поддержку обновление всё равно просит сравнение объектов?

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

Можно ли выполнить возврат на поддержку в клиент-серверной базе без остановки работы?

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