Как объединить две конфигурации 1С 8.3 в одну

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

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

Что подготовить до начала слияния

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

Что проверить заранее:

• 🧩 Версия платформы. Открывайте обе базы на одной версии 1С:Предприятие. Номер платформы должен быть не ниже того, на котором собрана более новая из конфигураций.
• 🔒 Возможность изменения. Типовая конфигурация стоит на поддержке и закрыта для правки. Без её открытия объединять нечего.
• ⚙️ Режим совместимости. Сравните Свойства конфигурации → Режим совместимости у обеих. Если режимы разные, часть объектов после слияния поведёт себя иначе.
• 📦 Файл второй конфигурации. Выгрузите её в .cf: Конфигурация → Сохранить конфигурацию в файл.

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

Какие есть способы объединить конфигурации и какой выбрать

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

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

Пошаговое слияние через сравнение и объединение

Порядок для полного объединения через .cf:

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

Шаг с F7 — та самая операция, что требует монопольного доступа. Пока идёт реструктуризация базы, работать в ней нельзя. Поэтому слияние и прогоняют на копии в нерабочее время, а в продуктив переносят уже готовый результат.

Как разрешать конфликты объектов при слиянии

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

Основной инструмент — приоритет. В настройке правил объединения задаётся, чья версия считается главной:

• Приоритет основной конфигурации — при расхождении остаётся то, что уже в базе; из файла добавляется только отсутствующее.
• Приоритет конфигурации из файла — наоборот, расходящиеся свойства перетираются версией из .cf.

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

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

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

Полезно сравнить спорные объекты по отдельности, не выполняя слияние: в дереве раскрывается детальное сравнение свойств, реквизитов и даже строк модуля. Так вы заранее увидите, что именно разойдётся, и примете решение по каждому объекту, а не вслепую по общему приоритету.

Перенос данных: справочники и документы между базами

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

Рабочие механизмы переноса:

• Выгрузка и загрузка данных в XML. Обработка с диска ИТС работает, когда структура объектов в базах совпадает. Подходит, чтобы перелить справочники и документы «один в один».
• Конвертация данных . Универсальный вариант, когда структуры различаются: правила сопоставляют объекты и реквизиты источника и приёмника.
• Формат EnterpriseData. В современных типовых обмен настраивается через универсальный формат — удобно для регулярной синхронизации, а не разовой заливки.
• Ручной ввод. Для десятка элементов проще забить руками, чем настраивать правила.

Порядок переноса обычно такой: сначала справочники (от независимых к подчинённым), затем остатки и только потом документы, которые на эти справочники ссылаются. Если залить документы раньше справочников, получите битые ссылки.

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

Ошибки, из-за которых объединение срывается

• 🚫 Конфигурация не открыта для изменения. Объекты в дереве сравнения заблокированы, слить ничего нельзя. Лечится настройкой поддержки.
• 🚫 Разные режимы совместимости. Объединение пройдёт, но часть кода и форм поведёт себя не так, как в исходной базе. Сверяйте режим заранее.
• 🚫 Неверный приоритет. Поставили приоритет файла там, где нужно было оставить основную, — и затёрли свои доработки. Проверяйте режим для ключевых объектов поимённо.
• 🚫 Разрешено удаление нужных объектов. В правилах объединения включили удаление того, чего нет в файле, — и из основной конфигурации пропали объекты. Включайте удаление осознанно.
• 🚫 Объединение прямо в рабочей базе. Реструктуризация заблокирует базу и оборвёт сеансы. Всегда на копии.
• 🚫 Ждали, что перенесутся данные. Слияние переносит структуру, а не записи. Данные — отдельным обменом.

Пакетное объединение и автоматизация

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

Что помогает:

• Файл настроек объединения. В окне сравнения настройки (какие объекты, какой приоритет) сохраняются в файл и переиспользуются при следующем слиянии той же пары конфигураций.
• Пакетный режим Конфигуратора. 1cv8 умеет запускать Конфигуратор без интерфейса ключом DESIGNER и выполнять операции обновления из командной строки. Точный набор ключей для вашей версии смотрите в справке: 1cv8 /? и 1cv8 DESIGNER /? — не полагайтесь на ключи из чужих заметок, они меняются между релизами платформы.
• 1C:EDT и Git. Для командной разработки конфигурацию выгружают в исходники и сливают ветки средствами системы контроля версий. Это самый предсказуемый способ объединять параллельные доработки: конфликты видно построчно, история сохраняется.

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

Проверка результата и производительность

После слияния конфигурация должна остаться рабочей — это проверяют до переноса в продуктив.

1. Проверка конфигурации. Конфигурация → Проверка конфигурации выявляет синтаксические ошибки модулей, битые ссылки на объекты и несогласованности. Отработайте все замечания.
2. Тестирование на копии. Прогоните ключевые операции: открытие основных форм, проведение документов, формирование отчётов. Объединение могло задеть объекты, которых вы не ожидали.
3. Тестирование и исправление базы. Для файловой базы после реструктуризации полезно проверить её целостность утилитой chdbfl.exe, для клиент-серверной — штатным тестированием информационной базы.

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