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