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

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

Главный риск: Физическая потеря данных при удалении расширения

Рассмотрим самый критичный аспект работы с расширениями, которые создают собственные таблицы в базе данных СУБД. Нам необходимо четко понимать физическую структуру хранения информации. Когда мы добавляем новый документ в расширение, платформа создает для него полноценные таблицы в базе данных так же, как и для объектов основной конфигурации.

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

Выясним, какие защитные механизмы предоставляет современная платформа 1С для предотвращения таких аварийных ситуаций:

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

Рассмотрим пример кода, с помощью которого мы можем проанализировать состав загруженных расширений и выявить те, которые хранят данные:

ВыборкаРасширений = РасширенияКонфигурации.Получить();
Для Каждого ТекущееРасширение Из ВыборкаРасширений Цикл
    Если ТекущееРасширение.ИзменяетСтруктуруДанных() Тогда
        ЗаписьЖурналаРегистрации("КонтрольРасширений",
            УровеньЖурналаРегистрации.Предупреждение,
            ,
            ,
            "Внимание! Расширение '" + ТекущееРасширение.Имя + "' содержит собственные таблицы данных и требует осторожности при манипуляциях!");
    КонецЕсли;
КонецЦикла;

Исторические проблемы с утилитой ТИИ (Тестирование и исправление)

Разберем ситуацию, упомянутую опытными разработчиками на форумах. В более ранних релизах платформы 1С v8.3 (в районе версий 8.3.14–8.3.15) существовала критическая ошибка работы платформенного механизма «Тестирование и исправление». При запуске ТИИ с определенными флагами (в частности, при реструктуризации или очистке ссылок) таблицы объектов, принадлежащих расширениям, могли очищаться или повреждаться.

Начиная с современных релизов платформы, эта проблема была полностью устранена. Процедура ТИИ теперь корректно обрабатывает метаданные расширений. Тем не менее, сам факт исторического наличия таких багов заставляет разработчиков с осторожностью относиться к хранению критически важных бизнес-данных в таблицах расширений, особенно если информационная база работает на устаревших релизах платформы.

Сложности интеграции и синхронизации данных в РИБ

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

1. Настройка планов обмена. Чтобы данные нового документа из расширения мигрировали в другие узлы, нам недостаточно просто создать объект. Нам придется заимствовать типовой план обмена (например, ОбменУправлениеТорговлейБухгалтерияПредприятия) в расширение и вручную добавлять туда наш новый документ для авторегистрации.
2. Подписки на события. В современных конфигурациях (таких как ERP, КА или УТ) регистрация изменений для обмена завязана на подписки на события. Нам потребуется заимствовать эти подписки в расширение и явным образом прописывать логику регистрации для нашего кастомного документа.
3. Ошибки при обновлении узлов. При синхронизации изменений метаданных в РИБ базы часто сталкиваются с коллизиями («Требуется загрузить критичные изменения»). Обновление конфигураций с «тяжелыми» расширениями в распределенной сети требует строгого соблюдения последовательности монопольных запусков на всех узлах.

Рекомендуемая архитектура доработки (Best Practices)

Как же поступить, чтобы не лишать себя преимуществ автоматического обновления типовой конфигурации и при этом гарантировать стопроцентную сохранность данных? Специалисты по внедрению крупных ERP-систем рекомендуют использовать гибридный подход.

Разберем этот подход по шагам:

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

Посмотрим на преимущества такой гибридной схемы:

• Абсолютная надежность: Данные хранятся в основной конфигурации. Случайно удалить их конфигуратором или ТИИ невозможно.
• Легкость обновления: Код обработчиков, кастомные экранные формы и бизнес-логика лежат в расширении. Типовая конфигурация обновляется без конфликтов кода.
• Упрощение обменов: Новые объекты основной конфигурации гораздо проще и надежнее включаются в типовые планы обмена и правила конвертации данных.

Резюме

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