Как перенести справочник в расширение 1С с сохранением ссылок и данных

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

Анализ основной проблемы: почему нельзя просто скопировать элементы

Рассмотрим ситуацию, с которой столкнулся автор темы. При попытке программного создания элементов в новом справочнике расширения он использовал следующий код:

Элемент = Справочники.СправочникВРасширении.СоздатьЭлемент();
ЗаполнитьЗначенияСвойств(Элемент, Выборка);
Элемент.УстановитьСсылкуНового(Выборка.Ссылка.УникальныйИдентификатор());
Элемент.Записать();

При выполнении этого кода возникает ошибка «Неверный параметр». Выясним причину: метод УстановитьСсылкуНового() ожидает в качестве аргумента объект типа Ссылка (например, СправочникСсылка.Номенклатура), а не УникальныйИдентификатор (GUID). Но даже если исправить синтаксическую ошибку, проблема не исчезнет.

Проанализируем структуру ссылки в 1С. Ссылка — это не только GUID. Она состоит из двух ключевых компонентов:

1. Уникальный идентификатор (GUID): 128-битное число, уникальное для конкретной записи.
2. Идентификатор типа метаданных (Metadata ID): внутренний номер, который платформа присваивает самому объекту «Справочник».

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

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

Если нам все же необходимо программно перенести данные с сохранением GUID (например, для синхронизации с внешними системами), мы должны использовать менеджер справочника для генерации правильной ссылки. Рассмотрим верный алгоритм:

// 1. Получаем GUID исходного элемента
Идентификатор = Выборка.Ссылка.УникальныйИдентификатор();

// 2. Формируем новую ссылку, используя менеджер справочника из расширения
НоваяСсылка = Справочники.СправочникВРасширении.ПолучитьСсылку(Идентификатор);

// 3. Создаем новый объект и устанавливаем подготовленную ссылку
НовыйОбъект = Справочники.СправочникВРасширении.СоздатьЭлемент();
ЗаполнитьЗначенияСвойств(НовыйОбъект, Выборка);
НовыйОбъект.УстановитьСсылкуНового(НоваяСсылка);
НовыйОбъект.Записать();

Этот код создаст элемент в расширении с тем же GUID, что был у оригинала. Однако помните: ссылки в документах все равно придется обновлять, так как тип метаданных изменился.

Стратегии полной миграции справочника

Разберем по шагам наиболее безопасные и эффективные способы переноса справочника.

Вариант 1: Использование обработки «Поиск и замена значений»

Это самый надежный способ с точки зрения целостности данных. Рассмотрим последовательность действий:

1. Создаем новый справочник в расширении со всеми необходимыми реквизитами.
2. Переносим данные программно (как показано в примере выше) или через универсальный обмен данными XML.
3. Используем стандартную обработку «Поиск и замена значений» (входит в состав БСП или инструментов разработчика).
4. В качестве «Что заменять» выбираем старый справочник, в качестве «На что заменять» — справочник в расширении.
5. Платформа автоматически найдет все упоминания в документах, регистрах накопления, сведениях и задачах, после чего выполнит перезапись движений.

Вариант 2: Выгрузка и загрузка через XML

Этот метод подходит, если вы планируете полностью удалить справочник из основной конфигурации. Посмотрим на этот процесс:

1. Выгружаем данные справочника с помощью обработки ВыгрузкаЗагрузкаДанныхXML.
2. Удаляем справочник из основной конфигурации (предварительно убедившись, что на него нет жестких ссылок в коде или других объектах).
3. Добавляем справочник в расширение с тем же самым именем.
4. Загружаем данные из XML обратно.

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

Работа с регистрами и итогами

Проанализируем ситуацию с регистрами. Если старый справочник использовался как измерение в регистре накопления, простая замена типа на составной (старый тип + новый тип из расширения) может привести к проблемам с итогами. Рассмотрим рекомендации:

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

Критически важные нюансы и риски

Рассмотрим дополнительные факторы, которые могут повлиять на работу системы после переноса:

1. Предопределенные элементы

Работа с предопределенными данными в расширениях ограничена. Если вы удалите справочник из основной конфигурации, обращения в коде вида Справочники.ИмяСправочника.ИмяПредопределенного перестанут работать. Вам придется переписывать код на поиск по коду или идентификатору, что усложняет поддержку.

2. Обмены данными

Если ваша база участвует в обмене (РИБ, EnterpriseData), перенос справочника в расширение гарантированно «сломает» правила обмена. Объекты расширений описываются в XML-пакетах иначе. Вам потребуется вручную корректировать правила выгрузки и загрузки.

3. Надежность расширения

Помните, что данные в расширении физически хранятся в отдельных таблицах СУБД (с префиксами). Если по какой-то причине расширение не подключится (например, после обновления платформы или из-за конфликта имен), данные станут недоступны, а ссылки в документах превратятся в «битые».

Альтернативный подход: Справочник-«пустышка»

Выясним, существует ли более безопасная альтернатива полному переносу. Иногда лучше оставить справочник в основной конфигурации, но максимально его облегчить:

1. Удалить из основного справочника все дополнительные реквизиты, оставив только Код и Наименование.
2. Всю новую бизнес-логику и новые реквизиты добавить через расширение.
3. Таким образом, тип ссылки (Metadata ID) сохраняется, документы продолжают работать корректно, а расширение обеспечивает необходимый функционал.

Этот метод избавляет от необходимости массовой замены ссылок по всей базе данных и минимизирует риски потери данных при сбоях расширения.