В процессе разработки на платформе 1С предприятия часто возникает ситуация, когда функционал, ранее распределенный по нескольким расширениям, необходимо консолидировать в одном месте. Основная сложность здесь заключается не столько в переносе программного кода, сколько в сохранении накопленных данных в справочниках и реквизитах. Прежде чем приступать к объединению, рекомендуется провести анализ состава расширений на наличие ошибок, чтобы избежать конфликтов процедур и функций. Если просто скопировать объекты через буфер обмена, платформа создаст новые внутренние идентификаторы, и связь с существующими таблицами базы данных будет потеряна. Разберем подробно, как решить эту задачу различными способами, проанализируем причины возникновения ошибок и выберем оптимальную стратегию.
Прежде чем переходить к действиям, выясним причину, по которой обычное копирование объектов (Ctrl+C / Ctrl+V) не позволяет перенести данные. У каждого объекта метаданных в 1С (справочника, документа, реквизита) есть скрытый от пользователя уникальный идентификатор (UUID). Именно по нему платформа сопоставляет объект в конфигурации с таблицей или колонкой в базе данных SQL.
Когда мы создаем дубликат объекта в новом расширении, ему присваивается новый UUID. С точки зрения системы — это совершенно другой объект, даже если его имя полностью совпадает со старым. Поэтому при удалении старого расширения таблицы в БД уничтожаются, а новые остаются пустыми. При попытке же объединить два расширения, где объекты создавались копированием, часто возникает ошибка: "Обнаружено пересечение внутренних идентификаторов". В таких ситуациях может потребоваться ручное сравнение и замена GUID (UUID) объектов в XML-выгрузках конфигураций. Это происходит потому, что платформа видит конфликт структур, претендующих на одно и то же пространство имен или данных.
Рассмотрим ситуацию с точки зрения долгосрочного сопровождения системы. Если новые справочники и реквизиты типовых объектов становятся неотъемлемой частью бизнес-логики, лучшим решением будет перенести их структуру в основную (расширяемую) конфигурацию. Такой подход подробно анализируется в рамках стратегий доработки типовых конфигураций.
Проанализируем преимущества этого метода:
Единственным минусом, как отмечают специалисты на примере 1С:ERP Управление предприятием, является небольшое увеличение времени автоматического обновления (циклы сравнения конфигураций могут занимать больше времени). Однако, если база обновляется в нерабочее время ("укладывается в ночь"), этот фактор не является критичным по сравнению с риском потери данных в расширениях.
Если добавление объектов в основную конфигурацию по каким-то причинам невозможно или нежелательно, воспользуемся методом ручной синхронизации идентификаторов. Нам нужно заставить новое расширение "думать", что его объекты — это те же самые объекты из старого расширения.
Разберем процесс по шагам:
Catalogs/СвойСправочник.xml).uuid. Скопируем это значение.uuid на скопированный.Configuration.xml в корне выгрузки, где регистрируются все объекты расширения. Идентификаторы там должны совпадать с идентификаторами в файлах объектов.После такой манипуляции платформа признает объекты идентичными, и данные "подцепятся" автоматически, так как SQL-имя таблицы завязано на UUID.
Посмотрим на ситуацию иначе: вместо того чтобы менять структуру конфигурации, мы можем просто перелить сами данные из одних таблиц в другие. Это наиболее безопасный способ, не требующий правки системных файлов. Для решения этой задачи отлично подойдет адаптивная выгрузка и загрузка данных XML, которая позволяет работать с не полностью идентичными конфигурациями:
Пример кода для программного переноса данных между реквизитами (если вы решили создать новые реквизиты программно):
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
Объект = Выборка.ПолучитьОбъект();
// Предположим, переносим данные из СтарыйРеквизит в НовыйРеквизит
Объект.НовыйРеквизит = Объект.СтарыйРеквизит;
Объект.ОбменДанными.Загрузка = Истина;
Объект.Записать();
КонецЦикла;
Проанализируем возможности современной среды разработки `EDT` (Enterprise Development Tools). В отличие от классического конфигуратора, рефакторинг и перенос объектов между расширениями в EDT реализован гораздо нагляднее:
Выясним, какой метод лучше выбрать в зависимости от ситуации:
Рассмотрим также важный нюанс: если ваша цель — просто использовать данные одного расширения в другом, не обязательно их объединять. Начиная с версии 8.3.15, платформа поддерживает взаимодействие расширений. Достаточно настроить назначение расширений и контролировать их порядок в списке, тогда программный код второго расширения сможет обращаться к экспортным методам и данным первого.