Администрирование · 12 мин
Конфигурация не является базовой в 1С: причины и способы решения
Почему 1С пишет «конфигурация не является базовой», как обновить изменённую конфигурацию, снять и вернуть поддержку без потери данных и доработок.
Сообщение «конфигурация не является базовой» появляется при попытке обновить типовую конфигурацию 1С, в которую вносились изменения: добавлены объекты, изменён код модулей, формы или макеты. Платформа сравнивает текущую конфигурацию с конфигурацией поставщика, видит расхождения и отказывается выполнять автоматическое обновление, чтобы не потерять чужие доработки.
Это не ошибка программы, а штатный защитный механизм. Типовое обновление заменяет объекты на новые версии поставщика, и если объект изменён вручную, бездумное обновление стёрло бы доработку. Поэтому система требует, чтобы администратор осознанно решил судьбу каждого изменённого объекта.
Задача сводится к тому, чтобы понять, какие объекты изменены, кто и зачем их менял, а затем выбрать один из трёх путей: выполнить сравнение и объединение с сохранением доработок, снять конфигурацию с поддержки и обновлять вручную, либо вернуть конфигурацию на полную поддержку, отказавшись от изменений.
Что означает сообщение и почему оно появляется
У каждой типовой конфигурации есть «конфигурация поставщика» — эталон, с которым платформа сверяет рабочую конфигурацию при обновлении. Пока объекты совпадают с эталоном, обновление проходит автоматически: старые версии объектов заменяются новыми без вопросов.
Как только разработчик или администратор включает возможность изменения и правит хотя бы один объект, конфигурация переходит в состояние «на поддержке с изменениями». С этого момента автоматическое обновление невозможно: платформа не знает, какие доработки нужно сохранить, а какие можно перезаписать.
Типичные причины, по которым конфигурация перестаёт быть базовой (типовой):
- изменены модули, формы, макеты или роли под требования организации;
- добавлены собственные документы, справочники, отчёты или обработки прямо в конфигурацию;
- предыдущий специалист правил конфигурацию, но не задокументировал изменения;
- обновление ранее выполнялось объединением с ошибками, и поддержка «рассинхронизировалась».
Первый шаг: резервная копия и анализ изменений
Любые манипуляции с поддержкой и обновлением начинайте с резервной копии. Для файловой базы достаточно скопировать файл 1Cv8.1CD при закрытых сеансах, для клиент-серверной — сделать выгрузку в dt через конфигуратор или средствами СУБД. Без копии откатить неудачное объединение будет невозможно.
Затем выясните, что именно изменено. Откройте конфигуратор и выполните: Конфигурация → Поддержка → Настройка поддержки. В окне будет видно, находится ли конфигурация на поддержке и включена ли возможность изменения. Для детальной картины используйте сравнение с конфигурацией поставщика: Конфигурация → Сравнить и объединить с конфигурацией из файла, либо через настройку поддержки кнопкой «Сравнить».
Отчёт о сравнении покажет список изменённых объектов. Пройдитесь по нему и классифицируйте каждый объект: доработка нужна и работает, доработка устарела и не используется, назначение изменения неизвестно. От этой классификации зависит выбор стратегии обновления.
Обновление через сравнение и объединение
Основной рабочий способ обновить изменённую конфигурацию — режим сравнения и объединения. Он позволяет для каждого объекта выбрать: взять новую версию поставщика, оставить свою доработку или объединить изменения.
- 1Сделайте резервную копию базы и убедитесь, что все пользователи вышли из системы.
- 2Откройте конфигуратор: Конфигурация → Поддержка → Обновить конфигурацию.
- 3Выберите источник обновления (файл поставки или каталог обновлений) и дождитесь построения отчёта о сравнении.
- 4В дереве сравнения снимите флажки с объектов, чьи доработки нужно сохранить, либо настройте объединение вручную для модулей.
- 5Для изменённых модулей откройте построчное сравнение и перенесите свои фрагменты кода в новую версию.
- 6Выполните объединение, затем обновите конфигурацию базы данных (F7) и проверьте работу доработок.
Ключевой момент — работа с изменёнными модулями. Если поставщик тоже правил тот же модуль, простой перенос галочки недостаточен: нужно открыть текстовое сравнение и аккуратно встроить свои изменения в новый код. Пропущенный фрагмент доработки обычно обнаруживается только при работе пользователей, поэтому после объединения проверяйте каждый сценарий, который затрагивали доработки.
Объекты, которые изменили вы, но не менял поставщик, при объединении сохранятся автоматически — достаточно не снимать с них защиту. Конфликты возникают только там, где правки сделаны с обеих сторон.
Перед объединением сохраните отчёт о сравнении в файл. Он станет чек-листом для проверки после обновления: по нему удобно пройтись и убедиться, что каждая доработка на месте и работает. Заодно этот файл служит документацией для следующего обновления.
Как вернуть конфигурацию на полную поддержку
Если анализ показал, что доработки больше не нужны (или их никогда не было, а изменения внесены случайно), конфигурацию можно вернуть к типовому состоянию. Тогда обновления снова будут проходить автоматически.
Делается это через загрузку конфигурации поставщика: Конфигурация → Загрузить конфигурацию из файла с указанием cf-файла нужного релиза, либо через настройку поддержки. Все изменённые объекты будут заменены эталонными версиями, добавленные вручную объекты придётся удалить отдельно — они мешают постановке на полную поддержку.
Перед возвратом на поддержку убедитесь, что доработки действительно не используются. Безобидная на вид правка печатной формы может оказаться критичной для отчётности, а удалённый реквизит документа — хранить данные, которые потом не восстановить из конфигурации поставщика.
Как проверить результат
В настройке поддержки объекты без пометок изменений, обновление доступно
Объекты помечены как изменённые или удалённые поставщиком
Все изменённые сценарии выполняются без ошибок
Ошибки «Процедура или функция не обнаружена», неверные данные в отчётах
Реорганизация прошла без сообщений о потере данных
Предупреждения об удалении реквизитов с данными
Снятие с поддержки: когда это оправдано
Полное снятие с поддержки (Конфигурация → Поддержка → Настройка поддержки → Снять с поддержки) разрывает связь с поставщиком. После этого типовые обновления применить нельзя — каждое придётся переносить вручную через сравнение с файлом cf нового релиза, что трудоёмко и требует квалификации.
Снимать с поддержки оправдано только в двух случаях: конфигурация переписана настолько, что от типовой мало что осталось, либо организация сознательно отказывается от обновлений поставщика и сопровождает решение своими силами. Для типовых учётных систем это почти всегда плохое решение: без обновлений быстро устаревает регламентированная отчётность и обмены с государственными сервисами.
Альтернатива снятию с поддержки — перевод доработок в расширения конфигурации. Расширения не меняют основную конфигурацию, поэтому она остаётся типовой и обновляется автоматически. Большинство типовых доработок — печатные формы, дополнительные отчёты, изменение поведения форм — реализуемы расширениями.
Сравнение вариантов
Подходит при небольшом числе доработок. Сохраняет и изменения, и возможность обновлений, но требует ручной работы при каждом релизе.
Подходит, если доработки не нужны. Даёт полностью автоматические обновления, но уничтожает все изменения.
Только при глубокой переработке конфигурации. Полная свобода изменений, но обновления поставщика переносятся вручную или игнорируются.
Лучший долгосрочный вариант: конфигурация становится типовой, доработки живут отдельно и не мешают обновлениям.
Типичные ошибки и частые сценарии
Обновление пропускает релизы
Если конфигурация не обновлялась давно, обновляйте последовательно через промежуточные релизы, указанные в инструкции поставщика. На изменённой конфигурации это особенно важно: чем меньше шаг, тем проще разобрать конфликты при объединении.
Доработки внесены, но автор недоступен
Типовая ситуация: прежний франчайзи что-то правил и не оставил описания. Постройте отчёт сравнения с конфигурацией поставщика, по текстам модулей и составу объектов определите назначение правок. Проверьте по журналу регистрации и опросу пользователей, какие функции реально используются. Неиспользуемые доработки — кандидаты на отказ при возврате к типовой.
Сообщение появляется при обновлении отраслевой конфигурации
У отраслевых решений поставщиком является не «1С», а фирма-разработчик решения, и обновления распространяются её cf-файлами. Логика та же: сравнение и объединение с конфигурацией поставщика, но источник обновления берите у разработчика отраслевого решения, а не из типового дистрибутива.
Как выбрать действие
Проверка после обновления
После объединения и обновления конфигурации базы данных пройдите контрольный список: откройте изменённые документы и проведите тестовые экземпляры, сформируйте доработанные отчёты и печатные формы, проверьте обмены, если они затрагивались правками. Ошибки в модулях проявляются при первом обращении к изменённому коду, поэтому прогонять нужно именно доработанные сценарии.
Отдельно проверьте журнал регистрации на наличие ошибок после запуска пользователей и убедитесь, что при реструктуризации не было предупреждений об удалении данных. Если такие предупреждения были — сверьте, не затронуты ли реквизиты, добавленные доработками.
Что важно запомнить
«Конфигурация не является базовой» — признак доработок, а не поломка. Порядок действий: резервная копия, анализ изменённых объектов, затем либо обновление через сравнение и объединение, либо возврат на полную поддержку. Оптимальная стратегия на будущее — держать конфигурацию типовой, а доработки выносить в расширения.
Часто задаваемые вопросы
Можно ли обновить изменённую конфигурацию без потери доработок?
Да, именно для этого существует режим сравнения и объединения. Для каждого изменённого объекта вы выбираете, какую версию оставить. Конфликтующие модули придётся править вручную через построчное сравнение текстов.
Что будет, если просто загрузить конфигурацию поставщика?
Все изменённые объекты будут заменены эталонными версиями, доработки в модулях, формах и макетах исчезнут безвозвратно. Данные в добавленных реквизитах могут быть удалены при реструктуризации. Делайте это только после резервной копии и анализа изменений.
Как узнать, кто и когда изменил конфигурацию?
Платформа не хранит полную историю изменений конфигурации. Косвенно помогает журнал регистрации (события изменения конфигурации), хранилище конфигурации, если оно использовалось, и комментарии в текстах модулей, которые оставляют разработчики.
Чем расширение лучше доработки конфигурации?
Расширение подключается поверх конфигурации, не изменяя её, поэтому конфигурация остаётся типовой и обновляется автоматически. Доработка внутри конфигурации требует ручного объединения при каждом обновлении. Расширениям поддаются большинство типовых задач: формы, печать, отчёты, дополнительная логика.
Можно ли вернуть снятую с поддержки конфигурацию обратно?
Да, через постановку на поддержку с загрузкой конфигурации поставщика того же релиза. Но все объекты будут приведены к эталону, а несовпадающие доработки потеряются, поэтому предварительно зафиксируйте список изменений и сделайте копию.
Почему после объединения появляются ошибки «Процедура не обнаружена»?
Чаще всего при объединении потерян фрагмент доработанного модуля: новая версия поставщика перекрыла ваш код, а вызовы из других объектов остались. Найдите по отчёту сравнения затронутые модули и перенесите недостающие процедуры из резервной копии конфигурации.