Как сравнить две конфигурации 1С 8.3 и найти отличия

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

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

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

Встроенное сравнение в Конфигураторе

Открывайте базу в Конфигураторе и заходите в Конфигурация → Сравнить конфигурации. В диалоге выбираются две сравниваемые конфигурации из доступных вариантов:

• 📦 Конфигурация — основная (редактируемая) конфигурация, которую вы открыли.
• 💾 Конфигурация базы данных — та, по которой реально работают пользователи. Расходится с основной, если вы вносили правки, но ещё не нажимали «Обновить конфигурацию базы данных».
• 🏭 Конфигурация поставщика — эталон вендора, если база на поддержке.
• 📁 Конфигурация из файла — любой внешний .cf.

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

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

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

Отчёт о сравнении и выгрузка результата

Дерево удобно смотреть глазами, но для согласования правок или передачи аналитику нужен документ. В окне сравнения откройте меню «Действия → Отчёт о сравнении». Платформа предложит настроить состав отчёта:

1. Выбрать, по каким конфигурациям строить (левая/правая колонка).
2. Отметить, включать ли только отличия или всё дерево.
3. Задать глубину — краткий список объектов или подробный разбор свойств и модулей.
4. Сформировать отчёт в табличный документ, который сохраняется в файл или печатается.

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

Сравнение файлов конфигураций .cf без рабочей базы

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

1. Создайте пустую информационную базу (можно файловую, для разовой задачи этого достаточно).
2. Загрузите в неё первый файл: Конфигурация → Загрузить конфигурацию из файла, укажите первый .cf.
3. Второй файл подключите через Конфигурация → Сравнить, объединить с конфигурацией из файла — выберите второй .cf.
4. Получите то же дерево отличий, что и при обычном сравнении.

Пакетный аналог для автоматизации — загрузка через командную строку Конфигуратора: 1cv8 DESIGNER /LoadCfg first.cf и затем работа с файлом. Выгрузка конфигурации в файл делается командой /DumpCfg.

Для сравнения именно файлов (а не загрузки в базу) в сообществе существуют внешние утилиты и обвязки. Если планируете это регулярно, надёжнее перейти к выгрузке в XML-файлы — следующий раздел.

Сравнение через выгрузку в файлы и Git

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

1cv8 DESIGNER /F "C:\base" /N "Администратор" /DumpConfigToFiles "C:\src"

Обратная загрузка — параметром /LoadConfigFromFiles. Получив текстовое представление, вы работаете с ним как с обычным исходным кодом:

• 🔀 кладёте папку src в репозиторий Git;
• после каждой доработки делаете коммит;
• отличия между версиями смотрите через git diff, между ветками — через стандартные инструменты слияния.

Такой подход даёт то, чего нет во встроенном сравнении: построчную историю, авторство правок (git blame), ветки под разные доработки и ревью изменений до их попадания в базу.

Ручная выгрузка и коммит быстро надоедают, поэтому используют готовые open-source обвязки на oscript — например, gitsync и precommit1c. Они автоматизируют выгрузку конфигурации в файлы и подготовку коммита, а внешние обработки и отчёты распаковывают в удобный для диффа вид. Эти инструменты не входят в поставку 1С, ставятся отдельно.

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

Разбор отличий при обновлении типовой конфигурации

Самое важное сравнение для тех, кто дорабатывает типовые, — трёхстороннее, в момент обновления. Запускается оно через Конфигурация → Поддержка → Обновить конфигурацию. После выбора файла поставки (.cf или .cfu) открывается окно слияния с тремя состояниями каждого объекта:

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

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

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

Что сравнивается: метаданные, реквизиты и модули

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

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

Разницу в структуре метаданных удобно фиксировать и через XML-выгрузку: имена файлов повторяют имена объектов, поэтому git diff на папке src сразу показывает, какие объекты и реквизиты появились, исчезли или изменили свойства.

Автоматизация сравнения в CI/CD

Если конфигурация хранится в Git, сравнение встраивается в конвейер сборки и не требует ручного запуска Конфигуратора. Типовая схема:

1. Разработчик выгружает конфигурацию в файлы и коммитит изменения.
2. CI-сервер (GitLab CI, Jenkins и аналоги) по пушу запускает пайплайн.
3. На шаге проверки выполняется git diff между ветками или сравнение с эталоном.
4. Результат — автоматический отчёт об изменениях к merge request.

Для запуска Конфигуратора в пакетном режиме внутри пайплайна применяют те же команды /DumpConfigToFiles и /LoadConfigFromFiles, обёрнутые в инструменты автоматизации (например, vanessa-runner или уже упомянутый gitsync). Так выгрузка, сборка .cf из файлов и проверки идут без участия человека.

Типичные ошибки при сравнении конфигураций

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