Можно ли использовать расширение для добавления нового документа в определяемые типы в 1С?

При разработке на платформе «1С:Предприятие 8.3» часто возникает задача интеграции новых документов или справочников в существующие подсистемы конфигурации. Классический пример — подключение нового документа к механизму присоединенных файлов Библиотеки стандартных подсистем (БСП). Для этого необходимо добавить новый документ в определяемые типы. В этой статье мы подробно разберем, можно ли использовать расширение конфигурации для решения этой задачи, с какими критическими рисками можно столкнуться и какие альтернативные подходы существуют.

Техническая возможность: версии платформы и режим совместимости

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

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

Критические риски реструктуризации и потери данных

Рассмотрим подробнее, почему многие опытные разработчики предостерегают от бездумного расширения определяемых типов и называют этот процесс «опасным инструментом». Основная проблема кроется в физической структуре таблиц базы данных СУБД.

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

Проанализируем основные опасности такого подхода:

1. Длительная реструктуризация. Если определяемый тип используется в реквизите крупного регистра или справочника с миллионами записей, то при обновлении конфигурации базы данных начнется масштабная реструктуризация таблиц. В СУБД будут создаваться новые колонки, переноситься данные и перестраиваться индексы. На крупных базах этот процесс может «повесить» систему на несколько часов.
2. Риск безвозвратной потери данных. Это самый опасный нюанс работы с расширениями. Представим ситуацию: вы добавили документ в определяемый тип через расширение, запустили систему в пользовательском режиме и заполнили реквизиты у тысяч существующих объектов новыми ссылками. Если по какой-то причине (ошибка при обновлении, невнимательность администратора) расширение будет удалено из базы данных или отключено («активно» снято), платформа мгновенно «сузит» тип данных обратно до стандартного. При этом все записанные данные в полях СУБД, которые ссылались на ваш тип данных, будут стерты или превратятся в битые ссылки вида «Объект не найден». Даже при повторном подключении расширения данные автоматически не восстановятся.

Проблемы при последующих обновлениях конфигурации

Выясним, как ведет себя такое расширение при регулярном обновлении типовой конфигурации (например, 1С:Бухгалтерии) от поставщика. При сравнении и объединении конфигураций разработчик может столкнуться со следующими сложностями:

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

Особенности работы с механизмами БСП (на примере Присоединенных файлов)

Довольно часто определяемые типы расширяют для интеграции с подсистемами БСП. Рассмотрим практическую задачу: нам нужно подключить новый документ к подсистеме «Присоединенные файлы».

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

1. Создать в расширении новый справочник для хранения самих файлов (например, НашНовыйДокументПрисоединенныеФайлы).
2. Связать созданный справочник с владельцем.
3. Настроить подписки на события для регистрации изменений и удаления присоединенных файлов при удалении документа-владельца.
4. Внедрить программную регистрацию объекта в переопределяемом модуле подсистемы работы с файлами.

Для наглядности приведем пример того, как выглядит программная настройка связи в модуле ПрисоединенныеФайлыПереопределяемый в процедуре ПриОпределенииНастроекВладельцевФайлов:

Процедура ПриОпределенииНастроекВладельцевФайлов(Настройки) Экспорт
    
    // Интегрируем наш новый документ в подсистему присоединенных файлов
    НастройкиВладельца = Настройки.Добавить();
    НастройкиВладельца.Владелец = Метаданные.Документы.НашНовыйДокумент;
    НастройкиВладельца.ТипХраненияФайлов = Перечисления.ТипыХраненияФайлов.ВТранзакцииИБ;
    
КонецПроцедуры

Альтернативный подход: точечное снятие с поддержки

Учитывая все вышеописанные риски утери данных при сбое расширений, во многих практических кейсах более надежным решением будет частичный отказ от концепции «чистого расширения» в пользу контролируемого изменения основной конфигурации.

Рассмотрим этот алгоритм подробнее:

1. Переводим основную конфигурацию в режим возможности изменения (сохраняя ее на поддержке поставщика).
2. Снимаем с «замка» (устанавливаем правило «Редактируется с сохранением поддержки») конкретный определяемый тип (например, ВладелецФайлов) и, если требуется, измерение целевого регистра.
3. Добавляем наш новый документ в состав типов непосредственно в основной конфигурации.

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

Рекомендации по безопасности и выбору решения

Подводя итог, сформируем чек-лист для принятия архитектурного решения:

• Когда можно использовать расширение определяемых типов: для быстрых хотфиксов, тестирования функционала на копиях баз, создания временных прототипов систем, или в небольших базах, где регулярно выполняются бэкапы, а риски долгой реструктуризации минимальны.
• Когда НЕЛЬЗЯ использовать расширение: в высоконагруженных и крупных информационных базах, в распределенных информационных базах (РИБ), где рассинхронизация структуры метаданных расширения на узлах гарантированно приведет к критическим ошибкам обмена, а также для долгосрочных проектов автоматизации с редким контролем со стороны администраторов.