1С: как вернуть конфигурацию поставщика

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

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

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

Когда требуется возврат к конфигурации поставщика

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

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

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

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

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

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

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

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

Способ 1: загрузка конфигурации из файла

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

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

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

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

Каталог шаблонов по умолчанию:
%APPDATA%\1C\1cv8\tmplts\
Файл типовой конфигурации: 1cv8.cf (в папке релиза дистрибутива)

Способ 2: возврат через настройку поддержки

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

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

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

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

Проверка результата после возврата

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

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

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

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

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

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

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

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

Альтернатива: расширение вместо возврата к типовой

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

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

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