При разработке расширений в системе 1С:Предприятие 8.3 разработчики часто сталкиваются с ситуацией, когда на начальном этапе было выбрано неверное назначение (например, Дополнение вместо Адаптация). Если расширение содержит только программный код, проблем не возникает. Однако, как только в расширение добавляются собственные реквизиты, справочники, документы или регистры, платформа жестко блокирует возможность изменения поля Назначение. Это связано с тем, что для каждого типа назначения предусмотрена своя логика работы со структурой базы данных и приоритетность применения программных модулей.
В этой статье мы подробно разберем, почему возникает это ограничение, и проанализируем доступные способы смены назначения расширения без потери накопленных данных.
Разберем причину такого поведения системы. Когда мы добавляем в расширение объект, влияющий на структуру данных, 1С создает в СУБД (SQL) реальные таблицы или колонки. Имена этих таблиц и способ их связки с основной конфигурацией зависят от внутреннего идентификатора расширения. Платформа разделяет расширения по приоритетам:
Смена назначения может привести к изменению порядка выполнения методов (аннотации &Перед, &Вместо, &После) и потенциальным конфликтам в структуре хранения. Поэтому 1С запрещает это действие «на лету».
Это самый безопасный и рекомендуемый метод для рабочих баз. Рассмотрим его по шагам:
Шаг 1. Создание нового расширения. Создадим новое расширение с правильным назначением (например, Адаптация). Настроим его префиксы и основные свойства аналогично старому.
Шаг 2. Перенос структуры метаданных. Воспользуемся функцией Сравнить, объединить с конфигурацией из файла. Для этого выгрузим старое расширение в файл .cfe и загрузим его структуру в новое расширение. Важно понимать, что при этом переносятся только описания объектов, но не сами данные в таблицах.
Шаг 3. Перенос данных. Напишем небольшую обработку, которая перекачает данные из старых объектов в новые. Рассмотрим пример кода для переноса данных справочника, созданного в расширении:
Процедура ПеренестиДанныеСправочника()
// Получаем выборку из старого справочника (старое расширение)
ВыборкаСтарая = РасширениеСтарое_Справочники.МойСправочник.Выбрать();
Пока ВыборкаСтарая.Следующая() Цикл
// Создаем элемент в новом справочнике (новое расширение)
НовыйЭлемент = РасширениеНовое_Справочники.МойСправочник.СоздатьЭлемент();
// Заполняем реквизиты
ЗаполнитьЗначенияСвойств(НовыйЭлемент, ВыборкаСтарая);
// Особое внимание GUID. Чтобы ссылки в документах не «поплыли»,
// желательно сохранять УникальныйИдентификатор
СсылкаНовая = РасширениеНовое_Справочники.МойСправочник.ПолучитьСсылку(ВыборкаСтарая.Ссылка.УникальныйИдентификатор());
НовыйЭлемент.УстановитьСсылкуНового(СсылкаНовая);
НовыйЭлемент.Записать();
КонецЦикла;
КонецПроцедуры
Шаг 4. Обновление ссылок. Если объекты старого расширения использовались в качестве типов данных в основной конфигурации или других расширениях, нам потребуется запустить процедуру Поиск и замена ссылок, чтобы заменить ссылки на объекты из старого расширения ссылками на объекты из нового.
Проанализируем ситуацию, когда данных очень много. В этом случае написание кода для каждого объекта может быть трудозатратным. Мы можем использовать стандартную обработку УниверсальныйОбменДаннымиXML.
Важный нюанс: Платформа 1С идентифицирует типы данных по внутренним именам. Если справочник в XML описан как Справочник.Расш1_МойОбъект, а в новом расширении он называется Справочник.Расш2_МойОбъект (из-за смены префикса или имени расширения), загрузка не произойдет автоматически. Потребуется предварительная правка XML-файла поиском и заменой или использование конфигурации «Конвертация данных» для сопоставления объектов. Для переноса данных между объектами с несовпадающими именами и префиксами можно применить обработку адаптивной выгрузки и загрузки данных через XML.
Если база данных работает на MS SQL Server или PostgreSQL и объем данных исчисляется миллионами строк, выгрузка в XML может занять вечность. Проанализируем, как можно «обмануть» систему на уровне СУБД.
Внимание: Этот метод крайне опасен и должен выполняться только после создания резервной копии и на тестовом контуре!
Выясним причину: 1С хранит соответствие объектов метаданных и физических таблиц SQL в таблице DBSchema. При удалении расширения 1С подает команду DROP TABLE. Чтобы сохранить данные, мы можем переименовать таблицы в SQL-менеджере:
EXEC sp_rename '_InfoRg123', '_InfoRg123_TEMP'.INSERT INTO _InfoRg456 SELECT * FROM _InfoRg123_TEMP (где 456 — ID таблицы нового расширения).Этот метод позволяет сохранить данные мгновенно, но требует глубоких знаний структуры таблиц 1С (таких как таблицы итогов регистров накопления, таблицы срезов регистров сведений и т.д.).
Разберем вариант, который часто обсуждается на форумах: правка файлов выгрузки. Если мы выгрузим конфигурацию расширения в файлы через стандартную команду конфигуратора, мы получим набор XML-файлов.
В файле описания конфигурации расширения (обычно это корневой XML) присутствует тег Purpose. Мы можем попробовать изменить его значение вручную:
<Purpose>Supplement</Purpose> --> <Purpose>Adaptation</Purpose>
Однако, как показывает практика (и сообщение 2 из обсуждения), при попытке загрузить измененные файлы обратно в базу, где расширение уже установлено, платформа выдаст ошибку: «невозможна смена назначения расширения, если расширение влияет на структуры данных». Платформа сверяет загружаемый манифест с уже существующей структурой в БД.
Следовательно, этот метод работает только если:
Выясним, какой путь выбрать именно вам. Если вы находитесь на этапе разработки и данных в базе еще нет (или они тестовые), самым простым решением будет удаление и повторная загрузка с исправленным назначением.
Если же база «боевая» и данные критически важны, рекомендуем придерживаться Метода 1. Хотя он требует написания кода, он гарантирует корректность ссылочной целостности и позволяет контролировать каждый этап миграции. Помните, что смена назначения на Адаптация — это нормальная практика, если вам потребовалось перехватывать методы, которые уже задействованы в других расширениях, или если вы хотите, чтобы ваши правки имели приоритет над «Дополнениями».
Всегда выполняйте подобные операции сначала на копии базы данных и проверяйте работоспособность всех связанных бизнес-процессов после переноса. Для проверки корректности вызовов процедур и поиска ошибок после смены приоритета расширения можно использовать конфигурацию для анализа расширений на наличие ошибок.