Сколько конфигураций может существовать в прикладном решении 1С

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

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

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

Какие конфигурации существуют в прикладном решении

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

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

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

Основная конфигурация и конфигурация базы данных: в чём разница

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

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

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

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

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

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

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

Конфигурация хранилища при командной разработке

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

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

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

Расширения как отдельные конфигурации

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

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

Как проверить и синхронизировать конфигурации

Порядок действий при подозрении на рассинхронизацию конфигураций в прикладном решении:

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

Для пакетной проверки и обновления удобно использовать командную строку конфигуратора:

1cv8 DESIGNER /F"C:\Bases\Trade" /UpdateDBCfg /Out"C:\Logs\update.log"

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

Типичные ошибки при работе с несколькими конфигурациями

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

Часто задаваемые вопросы