← На главную

Добрый день! Часто у разработчиков, особенно при работе с доработанными или поврежденными базами, возникает вопрос о внутреннем устройстве хранения конфигураций в 1С. Официально их три, но поведение системы при некоторых операциях, например, при откате к конфигурации базы данных, наводит на мысль о существовании некой "четвертой" конфигурации. Давайте вместе разберемся, так ли это, и проанализируем, как на самом деле связаны разные виды конфигураций.

Основная загадка, которую мы сегодня решим, звучит так: почему при выполнении команды "Вернуться к конфигурации БД" изменяется не только основная конфигурация, но и конфигурация поставщика?

Основные "игроки": три вида конфигураций

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

1. Основная конфигурация. Это наша "песочница", рабочее пространство разработчика в Конфигураторе. Все изменения, которые мы вносим в код, объекты метаданных, формы и модули, сначала попадают именно сюда. Она является своего рода черновиком будущих изменений.
2. Конфигурация базы данных (КБД). Это "боевая" версия конфигурации, с которой непосредственно работают пользователи в режиме "Предприятие". Она хранится в системных таблицах самой базы данных. Когда мы вносим изменения в основную конфигурацию и нажимаем F5 или F7 (Обновить конфигурацию базы данных), платформа сравнивает основную конфигурацию с КБД и применяет различия, реструктуризируя таблицы и обновляя логику. Напрямую редактировать КБД нельзя.
3. Конфигурация поставщика (КП). Это эталонная, "заводская" версия тиражного решения, например, от фирмы "1С". Она хранится в базе, если конфигурация находится на поддержке. Ее основная задача — служить точкой отсчета для обновлений. Сравнивая основную конфигурацию с конфигурацией поставщика, мы можем видеть, какие объекты были изменены нами, а какие — поставщиком в новом релизе.

Раскрываем "загадку четвертой конфигурации"

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

• Типовую основную конфигурацию.
• Восстановленную конфигурацию поставщика (из загруженного файла).
• Старую, измененную конфигурацию базы данных (так как от обновления отказались).

Затем, после очистки кэша, он выполнил команду Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД. Он ожидал, что основная конфигурация вернется к состоянию КБД, а конфигурация поставщика останется новой, восстановленной. Но на практике конфигурация поставщика тоже "откатилась" к своему исходному, поврежденному состоянию. Это и породило гипотезу о наличии четвертой конфигурации, которая хранит "старую" КП.

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

Когда вы обновляете конфигурацию базы данных (нажимаете F7), платформа сохраняет не просто структуру метаданных для пользователей. Она создает целостный "слепок" состояния системы на этот момент. Этот слепок включает в себя:

• Состояние конфигурации базы данных.
• Состояние конфигурации поставщика, которое соответствовало этой КБД в момент обновления.

Таким образом, команда Вернуться к конфигурации БД — это не просто "скопировать КБД в основную конфигурацию". Это команда "откатить рабочую область конфигуратора к последнему сохраненному целостному состоянию". А это состояние включает в себя и КБД, и ту версию КП, которая была актуальна на момент сохранения этого состояния.

Почему такой механизм необходим? Разбор на примерах

Такое поведение платформы — не ошибка, а продуманный механизм для обеспечения консистентности (целостности) данных и метаданных. Если бы КБД и КП откатывались независимо, это привело бы к хаосу и сделало бы невозможным корректное обновление. Рассмотрим пару ситуаций.

Пример 1: Обновление релиза

Представим, что у вас есть Бухгалтерия версии 3.0.100. Вы запускаете обновление до версии 3.0.101.

1. Вы загружаете файл обновления cfu.
2. Платформа обновляет вашу основную конфигурацию и конфигурацию поставщика до версии 3.0.101.
3. Однако вы еще не нажали "Обновить конфигурацию базы данных". Это значит, что ваша КБД все еще имеет версию 3.0.100, и пользователи работают на ней.
4. Теперь вы решаете отменить обновление и нажимаете Вернуться к конфигурации БД.

Что произошло бы, если бы КП не откатилась? Ваша основная конфигурация вернулась бы к версии 3.0.100 (состояние КБД), а конфигурация поставщика осталась бы 3.0.101. Система оказалась бы в рассинхронизированном состоянии. Как ей понять, что нужно обновиться, если основная конфигурация и так "старая"? Как корректно сравнить ее с новой КП? Это нарушило бы всю логику механизма поддержки.

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

Пример 2: Загрузка чужой конфигурации

Представим, у вас база с типовой "Управление торговлей" (УТ). Вы решили поэкспериментировать и загружаете в нее cf-файл от типовой "Бухгалтерии предприятия" (БП), но на вопрос "Обновить конфигурацию базы данных?" отвечаете "Нет".

• Ваша основная конфигурация и конфигурация поставщика теперь от БП.
• Ваша конфигурация базы данных все еще от УТ.

Теперь вы нажимаете Вернуться к конфигурации БД. Что должно произойти по логике? Конечно же, все должно вернуться к УТ. Благодаря связке КБД и КП, платформа корректно восстанавливает в основной конфигурации не только структуру УТ, но и конфигурацию поставщика от УТ. Если бы КП осталась от БП, вы бы получили неработоспособный "гибрид", который невозможно ни обслуживать, ни обновлять.

А что насчет нескольких конфигураций поставщика?

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

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

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