Перевод доработанной конфигурации на расширения — это важный этап в жизни любого проекта на платформе 1С:Предприятие 8.3. Основная цель этой процедуры — вернуть основную конфигурацию к максимально «типовому» виду, чтобы облегчить процесс последующих обновлений. Однако перед разработчиком встает серьезный вызов: как перенести не только программную логику, но и структуру данных (реквизиты, справочники, документы), не потеряв накопленную информацию. Проанализируем ситуацию и разберем по шагам наиболее эффективные методики переноса.
Прежде чем приступать к переносу, проанализируем ключевое различие в хранении данных. Реквизиты и объекты, созданные в основной конфигурации, хранятся в постоянных таблицах СУБД. Объекты расширения также создают таблицы, но их жизненный цикл напрямую зависит от наличия расширения в списке. Важный момент: если по какой-то причине расширение будет удалено из списка (например, при критической ошибке или неосторожности администратора), платформа мгновенно уничтожит соответствующие таблицы в базе данных вместе со всеми данными. Восстановить их можно будет только из бэкапа.
По этой причине многие специалисты придерживаются гибридной стратегии: метаданные (поля, таблицы) оставлять в основной конфигурации, а всю логику (код, формы) выносить в расширение. Если же ваша цель — полная очистка основной конфигурации, рассмотрим алгоритм полного переноса.
Если вы решили полностью перенести добавленные реквизиты или документы в расширение, придерживайтесь следующего плана действий:
пр_), чтобы избежать конфликтов имен при будущих обновлениях от вендора.Рассмотрим пример кода для обработки заполнения новых реквизитов в расширении на основе старых данных из основной конфигурации:
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНоменклатура = Выборка.ПолучитьОбъект();
// пр_ДополнительноеОписание - это реквизит в расширении
// СтароеОписание - реквизит в основной конфигурации
ОбъектНоменклатура.пр_ДополнительноеОписание = ОбъектНоменклатура.СтароеОписание;
Попытка
ОбъектНоменклатура.Записать();
Исключение
Сообщить("Ошибка при записи объекта: " + ОбъектНоменклатура.Ссылка);
КонецПопытки;
КонецЦикла;
Для минимизации изменений в структуре БД (как основной, так и расширения) рассмотрим вариант использования механизма «Дополнительные реквизиты и сведения» из состава Библиотеки стандартных подсистем (БСП). Это позволяет хранить данные в типовых таблицах, не меняя структуру метаданных вообще.
Выясним причину популярности этого метода: он универсален и безопасен при обновлениях. Однако работа с такими данными в запросах требует особого подхода через левое соединение. Проанализируем пример запроса для получения данных из дополнительного реквизита:
ВЫБРАТЬ
Штрихкоды.Номенклатура КАК Номенклатура,
ЕСТЬNULL(ДопРеквизиты.Значение, ЗНАЧЕНИЕ(Справочник.ЗначенияСвойствОбъектов.ПустаяСсылка)) КАК ЗначениеСвойства
ИЗ
РегистрСведений.ШтрихкодыНоменклатуры КАК Штрихкоды
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура.ДополнительныеРеквизиты КАК ДопРеквизиты
ПО ДопРеквизиты.Ссылка = Штрихкоды.Номенклатура
И ДопРеквизиты.Свойство.Наименование = "GPC"
Важный совет: избегайте создания булевских типов в дополнительных реквизитах. Платформа может некорректно обрабатывать пустые значения (NULL), что сделает невозможным точный отбор. Рекомендуется использовать перечисления или справочники с двумя явными значениями.
Часто при переносе доработок программисты сталкиваются с тем, что сравнение основной конфигурации с типовой (файл .cf) выдает массу ложных различий: «несоответствие порядков объектов» или различия в пустой справочной информации. Рассмотрим подробнее, почему это происходит.
Разберем техническую причину: это связано с особенностями хранения метаданных в формате XML. 1С может менять форматирование тегов (например, порядок вложенности font и b) или добавлять пустые контейнеры для языков (английский язык en), что конфигуратор воспринимает как различие. Чтобы вылечить эту проблему и увидеть реальные изменения, можно воспользоваться методом очистки XML-файлов конфигурации.
Если вы выгружаете конфигурацию в файлы, можно использовать регулярные выражения для удаления «мусора». Рассмотрим пример регулярного выражения для удаления лишнего форматирования в Notepad++:
Найти: (<font.+?>)|(<\/.+?>)|(<.?.?color.+?>)|(<link .+?>)
Заменить на: (пустая строка)
Также полезно нормализовать англоязычный контент, если он пуст:
Найти: <v8:lang>en</v8:lang>\r\n.*<v8:content>.*</v8:content>
Заменить на: <v8:lang>en</v8:lang><v8:content></v8:content>
При переносе кода в расширение придерживайтесь следующих правил:
&Логика (или &Вместо, &Перед, &После) осознанно. Наиболее гибким считается метод &После, так как он минимизирует риск поломки базовой логики при обновлении.&После("ПриЗаписи") Процедура пр_ПриЗаписи(Отказ). Это защитит ваш код от конфликтов, если 1С в будущем добавит свою процедуру с таким же именем.Подводя итог, можно сказать, что перенос доработок в расширение — это процесс, требующий ювелирной точности. Если ваша конфигурация активно используется, безопаснее всего оставить реквизиты в основной конфигурации (сняв их с поддержки или оставив как «не редактируемые» в плане структуры), а всю программную логику перенести в расширение. Это даст вам преимущества легкого обновления и гарантированную сохранность данных.