Как добавить новое измерение или ресурс в типовой регистр сведений при использовании расширений?

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

В этой статье мы подробно разберем, как обойти это ограничение, проанализируем различные стратегии решения задачи и выясним, какой метод лучше выбрать в зависимости от требований к обновляемости базы и сложности задачи.

Почему нельзя просто добавить поле в расширение?

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

Вариант 1. Создание параллельного регистра в расширении

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

Разберем алгоритм реализации этого метода:

1. Создание объекта: В расширении создаем новый регистр сведений (например, Наш_ИсторияКадровыхРезервов).
2. Состав полей: Копируем в него все измерения из типового регистра, которые необходимы для связи, и добавляем наше новое измерение или ресурс.
3. Синхронизация записей: Нам необходимо обеспечить запись данных в оба регистра одновременно. Проанализируем, как это сделать. Лучшим вариантом будет использование подписки на события, созданной прямо в расширении.

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

// В расширении создаем подписку на событие ПередЗаписью для набора записей типового регистра
Процедура ПередЗаписьюНабораТиповогоРегистра(Источник, Отказ, Замещение) Экспорт
    
    // Источник — это НаборЗаписей типового регистра
    // Создаем набор записей для нашего нового регистра из расширения
    НашНабор = РегистрыСведений.Наш_ИсторияКадровыхРезервов.СоздатьНаборЗаписей();
    
    // Копируем отборы (например, по регистратору или ключевым измерениям)
    Для Каждого ЭлементОтбора Из Источник.Отбор Цикл
        Если НашНабор.Отбор.Найти(ЭлементОтбора.Имя) <> Неопределено Тогда
            НашНабор.Отбор[ЭлементОтбора.Имя].Установить(ЭлементОтбора.Значение);
        КонецЕсли;
    КонецЦикла;
    
    // Переносим данные из типового набора в наш
    Для Каждого ЗаписьТиповая Из Источник Цикл
        НоваяЗапись = НашНабор.Добавить();
        ЗаполнитьЗначенияСвойств(НоваяЗапись, ЗаписьТиповая);
        
        // Здесь заполняем наше новое поле, если оно доступно в контексте
        // Например, если данные есть в ДополнительныхСвойствах набора или документа
        Если ЗаписьТиповая.Регистратор <> Неопределено Тогда
            НоваяЗапись.НашеНовоеПоле = ЗаписьТиповая.Регистратор.НашРеквизитДокумента;
        КонецЕсли;
    КонецЦикла;
    
    НашНабор.Записать(Замещение);
    
КонецПроцедуры

Преимущества: Основная конфигурация остается на полной поддержке («на замке»).
Недостатки: Удвоение объема данных в базе, сложность построения отчетов (нужно соединять две таблицы в запросе), необходимость переноса старых данных разовой обработкой.

Вариант 2. Изменение основной конфигурации с сохранением поддержки

Если новое поле критически важно для работы системы (например, оно должно быть именно измерением и влиять на уникальность записей), лучше отказаться от идеи использования расширения для этой конкретной задачи и внести изменения в cf.

Рассмотрим, как сделать это правильно, чтобы не возникло проблем при последующих обновлениях:

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

Этот метод считается более надежным для сложных систем класса ERP или ЗУП, так как он гарантирует целостность данных на уровне СУБД.

Вариант 3. Использование механизма дополнительных сведений (БСП)

Если ваша конфигурация построена на базе БСП (Библиотеки Стандартных Подсистем), например, ЗУП 3.1 или УТ 11, проанализируем возможность использования «Дополнительных сведений».

Если новое «измерение» нужно только для аналитики в отчетах и оно логически привязано к документу-регистратору, мы можем:

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

Это позволит вообще избежать программирования и изменения структуры таблиц.

Важные выводы по итогам анализа

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

Запомните ключевые правила:

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

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