В современной практике разработки на платформе 1С все чаще возникает задача перевода кастомизированных конфигураций на «типовые» рельсы. Основная цель — максимально очистить основную конфигурацию от изменений, чтобы упростить процесс обновления. Однако, когда речь заходит о переносе не просто кода, а целых объектов метаданных, хранящих данные (документы, справочники, регистры), мы сталкиваемся с серьезными архитектурными вызовами. В этой статье мы подробно рассмотрим процесс переноса доработок в расширение, проведем анализ состава расширений на наличие ошибок и выработаем оптимальную стратегию работы.
Рассмотрим стандартный алгоритм действий, который обычно предполагается при решении данной задачи. Процесс включает в себя не только копирование метаданных, но и миграцию накопленной информации. Разберем по шагам:
Рассмотрим подробнее программный способ переноса движений. Чтобы не перепроводить документы, мы можем прочитать набор записей регистра, заменить в нем Регистратор и записать обратно. Посмотрим на пример логики такой обработки:
Для Каждого СтрокаДокумента Из СписокСтарыхДокументов Цикл
НовыйДокумент = Документы.Префикс_МойДокумент.СоздатьДокумент();
ЗаполнитьЗначенияСвойств(НовыйДокумент, СтрокаДокумента.Ссылка);
НовыйДокумент.УстановитьСсылкуНового(НовыйУИД); // Если нужно сохранить GUID
НовыйДокумент.Записать();
// Перенос движений по типовому регистру
Набор = РегистрыНакопления.Продажи.СоздатьНаборЗаписей();
Набор.Отбор.Регистратор.Установить(СтрокаДокумента.Ссылка);
Набор.Прочитать();
Если Набор.Количество() > 0 Тогда
НовыйНабор = РегистрыНакопления.Продажи.СоздатьНаборЗаписей();
НовыйНабор.Отбор.Регистратор.Установить(НовыйДокумент.Ссылка);
Для Каждого Движение Из Набор Цикл
ЗаполнитьЗначенияСвойств(НовыйНабор.Добавить(), Движение);
КонецЦикла;
НовыйНабор.Записать();
КонецЕсли;
КонецЦикла;
Проанализируем ситуацию с точки зрения хранения данных в СУБД. В платформе 1С данные расширений хранятся в отдельных таблицах. Это порождает несколько критических рисков, которые мы должны учитывать:
Риск 1: Безвозвратное удаление данных. Если администратор случайно или намеренно удалит расширение из списка в Конфигураторе, платформа физически удалит таблицы этого расширения. Чтобы минимизировать человеческий фактор при управлении множеством расширений, рекомендуется использовать инструмент групповая обработка расширений базы, позволяющий централизованно управлять их активностью и безопасным режимом.
Риск 2: Конфликты при обновлении. Одной из целей переноса является «автообновление». Однако, если расширение заимствует типовые объекты, структура которых меняется в новом релизе 1С, расширение может просто не подключиться. В этом случае пользователь не увидит своих документов, а типовые отчеты могут выдать ошибки из-за «битых» ссылок.
Риск 3: Проблемы с GUID. Выясним причину важности уникальных идентификаторов. Если старый документ имел ссылки во внешних системах, то при создании документа в расширении без явного переноса УникальныйИдентификатор, все старые ссылки превратятся в <Объект не найден>. При программном переносе обязательно используйте метод УстановитьСсылкуНового().
Разберем ситуацию, когда документ из расширения двигает типовой регистр из основной конфигурации. Это «смешанный» режим работы, который является наиболее опасным. Рассмотрим подробнее почему:
Если расширение будет отключено или удалено, записи в таблицах итогов и оборотов регистра останутся, но поле Регистратор будет содержать ссылку на несуществующий тип объекта. Это приведет к тому, что:
Проанализируем работу расширений в условиях РИБ. Если ваша база данных распределенная, перенос документов в расширение превращается в сложный технологический процесс. Для корректной миграции данных необходимо, чтобы структура расширения была идентична во всех узлах. На практике это часто приводит к «развалу» обмена в крупных сетях при несвоевременном обновлении расширений на периферии.
Посмотрим на ситуацию здраво. Чтобы достичь цели легкого обновления и при этом не подвергать данные риску, рекомендуется придерживаться следующей стратегии:
&Перед, &После или &Вместо.Существует известная ошибка платформы, когда тестирование и исправление базы не может исправить повреждения в служебных таблицах расширений. Чтобы вовремя обнаружить подобные проблемы, полезно проводить регулярный анализ конфигураций, расширений, отчетов и обработок на наличие ошибок. Это позволит выявить некорректные вызовы функций и процедур еще до того, как они приведут к сбою системы.
Подведем итог: Перенос функционала в расширение — это отличный способ упростить сопровождение. Но перенос структуры данных — это риск, который должен быть обоснован. Если данные критически важны и накапливаются годами, оставьте их в основной конфигурации. Это обеспечит максимальную надежность, предсказуемость при обновлении и стабильность работы отчетов.