Как перенести подсистему из одной конфигурации 1C в другую

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

Существует два основных способа: сравнение и объединение конфигураций (подходит, когда обе конфигурации доступны в конфигураторе) и перенос через выгрузку в файлы XML (удобен, когда исходная конфигурация хранится в формате EDT или получена от стороннего разработчика). Выбор зависит от формата исходников и объёма переносимого функционала.

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

Что входит в подсистему и почему перенос сложнее, чем кажется

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

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

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

Подготовка: резервная копия и анализ зависимостей

Начните с создания выгрузки целевой базы через «Администрирование — Выгрузить информационную базу» или средствами СУБД, если база клиент-серверная. Дополнительно выгрузите саму конфигурацию в файл .cf — это позволит быстро откатиться, если объединение пойдёт не так.

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

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

Способ 1: сравнение и объединение конфигураций

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

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

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

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

Способ 2: перенос через выгрузку в файлы XML

Если исходная конфигурация поставляется в виде выгрузки в файлы (формат конфигуратора или EDT), удобнее работать через загрузку из файлов. В конфигураторе целевой базы выберите «Конфигурация — Загрузить конфигурацию из файлов» — но этот вариант заменяет конфигурацию целиком, поэтому для частичного переноса он не подходит напрямую.

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

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

Сравнение способов переноса

Сравнение и объединение из .cf

Подходит в большинстве случаев; наглядный контроль каждого объекта. Ограничение: нужен готовый файл конфигурации источника.

Копирование объектов в EDT

Удобно при разработке в EDT и переносе между проектами. Ограничение: зависимости переносятся не всегда полностью, требуется ручная доработка.

Выгрузка/загрузка XML целиком

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

Перенос кода, прав и интерфейса

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

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

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

Проверка результата и обновление базы данных

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

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

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

Контрольные точки

Как проверить результат

Проверка конфигурации

Норма

Нет ошибок компиляции модулей и некорректных ссылок

Тревожный признак

Ошибки вызовов несуществующих процедур и ссылок на отсутствующие объекты

Отображение раздела

Норма

Подсистема видна в панели разделов, команды открывают формы

Тревожный признак

Раздел пустой или не отображается у пользователей

Права доступа

Норма

Пользователь с нужной ролью создаёт и проводит документы

Тревожный признак

Ошибка «Нарушение прав доступа» при открытии объектов

Проведение документов

Норма

Движения по регистрам формируются корректно

Тревожный признак

Документ проводится без движений или с ошибками обработчиков

Частые вопросы по переносу подсистем

Можно ли перенести подсистему без доступа к исходной базе?

Да, если у вас есть файл конфигурации .cf или выгрузка конфигурации в файлы XML. Из выгрузки сначала собирается .cf через загрузку в пустую базу, затем используется стандартное сравнение и объединение. Без файла конфигурации перенести метаданные штатными средствами нельзя.

Что делать, если в целевой конфигурации уже есть объекты с такими же именами?

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

Переносятся ли данные вместе с подсистемой?

Нет. Сравнение и объединение переносит только метаданные — структуру, код, роли и интерфейс. Данные (элементы справочников, документы, записи регистров) переносятся отдельно, например через «Универсальный обмен данными в формате XML» или обработку выгрузки/загрузки через EnterpriseData, если нужно заполнить новую подсистему информацией из старой базы.

Как перенести подсистему из БСП (библиотеки стандартных подсистем)?

Подсистемы БСП сильно связаны между собой и с ядром библиотеки, поэтому выдернуть одну «в чистом виде» сложно. Рекомендуемый путь — внедрять БСП целиком или по официальным инструкциям внедрения конкретной подсистемы из документации к библиотеке, где перечислены обязательные зависимые объекты и порядок их переноса.

Нужно ли снимать целевую конфигурацию с поддержки?

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

Почему после переноса подсистема не видна пользователям?

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